Datum:
Hallo, nach zwei Jahren Arbeit im Verborgenen darf ich euch nun mein Selbstbau-Hausbussystem vorstellen, ich habe es OpenHC genannt. Am Wochenende habe ich endlich was in Sorceforge eingerichtet: http://openhc.sourceforge.net/ (Layoutdateien und ein "echter" Software-Release fehlen noch.) Es handelt sich um zum PHC-Bus der Fa. Peha kompatible Module, Software, etc. Etliches an Infrastruktur. Hardware und Firmware sollte professionellen Ansprüchen genügen, ich habe mir viel Mühe gegeben. So gibt es für meine Module eine Firmwareupdatemöglichkeit über den Bus (!), auslesbare Fehlerspeicher, Firmware natürlich mit Interrupts, Schlafmodi, Watchdog und so, energiesparendes Pulsen von Relais zum Halten, Versorgung über DC/DC Wandler wo sinnvoll. Ich sehe den großen Vorteil darin, dass es nicht eine weitere Insellösung ist, mit der z.B. kein Nachbesitzer was anfangen kann, sondern bisher ein kommerzielles System. Da kann man nach Belieben dazukaufen oder nun dazubauen, je nach Zeit oder Fähigkeiten. Wer sich mit PHC partout nicht anfreunden mag (man braucht eine zentrale Steuerung, und die muß man original kaufen) kann auch nur die Hardware verwenden und ein eigenes Protokoll aufsetzen, aber dann sind wir wieder auf der Insel. Und das meiner Ansicht nach große Problem des "Authorings", wie programmiere ich die Anlage. Jetzt bin ich gespannt auf eure Reaktionen, hoffe das Wiki durch Fragen etc. zu verbessern. Noch ist es eine recht oberflächliche Beschreibung, viele Datails fehlen noch, ich arbeite dran. Aber die Schaltpläne sind da, der uC-Code auch (in Subversion eingecheckt), viele Fotos. Vielleicht finden sich ja noch Mitstreiter, das wäre der beste Erfolg. Noch 2 Links zum Thema PHC: Hersteller: http://www.peha.de unabhängiges User-Forum: http://phc.foren-city.de/
Datum:
Hmmm, erst mal einlesen, was es mit PEHA so auf sich hat - kannte ich noch gar nicht... Was kost'n so 'ne Steuereinheit (Größenordnung)? Und wie stellen die sich dazu, wenn man da plötzlich so kompatible Module ins Netz stellt? ((edit)) Ok, hab's gerade im PHC-Forum gelesen: Nicht gerade himmelhoch begeistert, aber man hat's auch nicht direkt verboten :-)) ((/edit)) Auf jeden Fall schon mal grosses Lob für die OpenHC Seite. Super gemacht!
Datum:
Respekt! Das setzt den Standard. Habe mir mal die Docs bei Sourceforge angesehen und einen Ausflug ins PHC-Forum unternommen. Aber genauere Aussagen zum Protokoll gibt es dort nicht. Die Sache finde ich sehr interessant, da ich im Moment an einer prinzipiell sehr ähnlichen Eigenbaulösung zugange bin (HW, Protokoll und SW). Hast du zur Entwicklung deiner Module das Protokoll durch sniffen reverse engineered oder bist du an Insiderinfos dran gekommen? Aber nochmals Hut ab für den Profi-touch. Grüße Cooberpedy
Datum:
Ein Bus System dessen Protokoll nicht offen liegt hat bei mir sowieso keine Chance, aber du hast das Protokoll ja irgendwie rausbekommen (Infos dazu wären interessant). Was spricht dagegen eine eigene zentrale Steuerung zu bauen?
Datum:
Hallo nochmal, ich bemühe mich um ein paar Antworten. @Stefan: Es gibt/gab gerade einen Generationswechsel bei der Steuerung. Für OpenHC taugen beide. Die alte heißt 940 STM, gab es mit und ohne Display, ohne ca. 100€ billiger. Man kann aber selbst ein Standarddisply anschließen, es fehlt intern einfach nur. Die neue heißt 941 STM, gibt es meines Wissens nach nur mit Display. Im Unterschied ist sie Flash-updatefähig (Zukunftspotential) und hat auch USB. Kostet laut Preisliste Peha 660€ + MWSt, keine Ahnung was das für Straßenpreise ergibt. Vielleicht gibt es irgendwo noch günstig das alte Modell. Die neue hat z.Zt. kaum Vorteile. @Cooberpedy: Ich habe das Protokoll belauscht. Es ist recht gradlinig, wenn man das System erst mal erkannt hat. Ein Bustelegramm besteht byteweise betrachtet aus Zieladresse, Länge, "Payload" und einem 16bit CRC. Das MSB der Länge ist ein Toggle-Bit, um Retries von neuen Paketen unterscheiden zu können. Jedes Telegramm wird vom Empfänger quittiert, beim Ausbleiben gibt es Retries. Die "Payload" besteht dann aus z.B. Schaltbefehlen oder Zustandsänderungen von einzelnen Kanälen. Ich werde das noch genauer dokumentieren. @Tim: Infos zum Rausbekommen oder zum Protokoll? Am Anfang wußte ich gar nichts, also erstmal Oszilloskop, dann Soundkarte zu Langzeitaufzeichnung (sehr nützlich!), dann Pegelwandler an RS232, dann ein immer weiter ausgebautes Logging-Programm und systematische Testprogrammierung der Steuerung, um alle Features durchzurastern. Die CRC-Generierung war ein Hindernis. Ich hatte sogar ein Programm geschrieben, was meine mitgeschnittenen Pakete mit allen Polynomen und Startwerten abklappert, aber letztendlich war es ein Standard-CCIR-CRC. Sicher kann man eine eigene Steuerung bauen, die hart codiert das tut, was die eigene Anlage soll. Aber wenn man das frei per Windows-Software (Drag+Drop, grafisch, etc.) programmierbare Verhalten der Originalsteuerung nachbilden will sehen wir uns hier in einigen Jahren wieder... Das Ding ist eine Art SPS, spezialisiert auf Haussteuerung. Ihr könnt die Windows-Software ausprobieren, dazu braucht man keine Hardware. Kann man bei Peha nach Registrierung downloaden, Beispielprojekte gibt es auch.
Datum:
Ich habe einen guten Anlass, meinen Thread noch mal nach oben zu kicken: Soeben habe ich den ersten offiziellen Release auf Sourceforge hochgeladen: http://sourceforge.net/project/showfiles.php?group_id=203571 Da gibt es nun also den Quellcode, ohne Subversion installieren zu müssen, sowie ausführbare Dateien (meine Tools) und Hexfiles für die Controller.
Datum:
Hallo Jörg. Habe mit Interesse Deine Beiträge gelesen und hätte Lust, mich zu beteiligen. In der Vergangenheit habe ich mal eine Stuereinheit für Jalousie- und Rollandenantriebe gebaut, die einige Komfortfunktionen hat wie z.B. bestimmte Positionen anfahren usw. Das Modul arbeitet ebenfalls mit RS485-Bus, allerdings derzeit noch mit meinem eigenen Protokoll. Lieber wäre mir eine breitere Basis. Wenn Du also Deine Ergebnisse in Sachen Protokoll bereitstellen würdest, könnte ich das implementieren. Ein paar Änderungen wären an dem Aktor allerdings noch zu machen, denn derzeit verwendet er ein paar exotische Teile.
Datum:
Mitstreiter sind immer willkommen! Ich habe noch nicht ganz verstanden, was du bauen willst. An deiner vorhandenen Steuerung + Aktoren das Protokoll gegen PHC austauschen? Was ist in deiner Hardware drin, was für Controller? Einen Rolladenaktor habe ich ja schon, siehe Wiki. Das Protokoll sollte ich mal veröffentlichen, das fehlt noch. Ich habe eine recht übersichtliche Excel-Tabelle, muss ich mal aufbereiten. Im Prinzip ist das aber schon jetzt kein Geheimnis für jeden der den Sourcecode lesen kann. Eine "offene" Steuerung gibt es nicht, allerdings ist das durch mittlerweile fortgeschrittenes Reverse-Engineering in den Bereich des Möglichen gerückt. Wir kennen jetzt den Aufbau der binären Datei, die von der GUI-Software in die Steuerung programmiert wird. Es fehlt jemand, der dazu Lust hat, wir haben die Steuerung damals gekauft und sind versorgt.
Datum:
Hallo Jörg. Ich habe mit Begeisterung dein Jetziges Projekt bewundert. Ich hätte sehr viel Interesse daran an diesem Projekt mitzuarbeiten. Was mir z.b. noch so vorschweben würde ist ein Display worüber man zusätzlich nochmal alles steuern kann. Ach so, und Könntest du mir nochmal erklären wieso man die Original Steuereinheit kaufen muss? Basti
Datum:
Hallo Sebastian, man kann theoretisch auch eine Steuerung nachbauen (siehe Beitrag über deinem). Ist bisher nicht passiert, weil kein "Leidensdruck" bestand. In voller Ausprägung wäre das ein recht heftiges Projekt. Kollege Jo hat allerdings eine PC-Simulation in Arbeit, davon könnte man abgucken. Für den echten Betrieb wäre ein embedded-System schon vorzuziehen, der PC hat so große Latenzen daß die Module "ungeduldig" werden und den Bus mit Retries belasten. Für PHC gibt es auch ein Display zu kaufen, siehe Peha-Katalog. Ist allerdings sehr teuer und optisch nicht besonders ansprechend. Insofern wäre das auch ein schönes Projekt. Wenn man es kompatibel zum Originaldisplay halten will bedeutet das aufwändiges Reverse-Engineering, für das man ferner ein Original braucht. Die Objektbeschreibung müßte aus dem Datensatz analysiert werden, der in das Display übertragen wird. Einfacher ist ein "eigenständiges" Display, dann kann man aber das Layout nicht mit der Windows-Software von Peha bearbeiten, braucht eine eigene Lösung. Du könntest auch die Web-Visualisierung von Jo verwenden und einen Browser "unterputzen", z.B. ein Nokia N770/N800.
Datum:
Also ich werde jetzt erstmal probieren eine Steuereinheit nachzubauen. Wenn man es ganz lapidar betrachtet, ist es doch nichts weiter als eine sterung die bei eingangsignalen die programierten ausgangssignale schaltet oder? Mir schwebt eine schaltung mit einem ATmega vor... vielleicht noch mit einer Speicherkarte und einem Web Server? Was haltet ihr von der idee? Basti
Datum:
Sebastian wrote: > Also ich werde jetzt erstmal probieren eine Steuereinheit nachzubauen. > Wenn man es ganz lapidar betrachtet, ist es doch nichts weiter als eine > sterung die bei eingangsignalen die programierten ausgangssignale > schaltet oder? Im Prinzip ja. Zusätzlich hat die Steuerung noch Uhren und Merker als interne Resourcen. Die "Aufgabe" ist sicher skalierbar, man kann kann erstmal klein anfangen mit einer hart codierten Steuerung, das später durch ladbare Tabellen ersetzen. Dann stellt sich die Frage nach einer Authoring-Software. An dem Punkt kann man es dann entweder kompatibel zum Original halten oder versuchen sein eigenes Ding hochzuziehen. > Mir schwebt eine schaltung mit einem ATmega vor... vielleicht noch mit > einer Speicherkarte und einem Web Server? Ziemlich genau so täte ich mir das auch vorstellen. ;-) Das Original hat noch ein einfaches Display (2*16 Zeichen) und ein paar Tasten, mit denen man Schaltzeiten und Uhr stellen kann, ferner Meldungen drauf ausgeben kann. Es gab aber auch eine Version ohne, ist kein Muß. In die Programmierung kann man dort nicht eingreifen, nichts abfragen oder auslösen. Schick mir doch mal eine PM, dann können wir uns über Skype oder Telefon mit höherer Bandbreite austauschen. Jörg
Datum:
Hmmm... gefällt mir sehr, die professionelle Art, mit der Du arbeitest. Ich überlege schon die ganze Zeit, eine zentrale Steuereinheit dafür zu bauen...
Datum:
@Wolfgang: nur zu! Die Voraussetzungen sind mittlerweile gut, Jo's Steuerungs-Emulator unter Windows funktioniert. Interessanterweise ist die Latenz doch kein Problem, wenn er statt über die serieller Schnittstelle des PCs mit einem LAN-Umsetzer auf RS485 spricht. Anscheinend ist Windows drauf optimiert, das Netzwerk-Applikationen zügig arbeiten können, weniger hingegen mit dem COM-Port. Aber das nur am Rande, vermutlich will niemand seine Haus-Steuerung einem Windows-PC überantworten? Eine mögliche Idee ist, eine Software-Steuerung auf einem Open-Source Router laufen zu lassen, oder anderen Linux-fähigen always-on Gerätschaften die sich im Hause finden. Den Übergang auf den "echten" Modulbus kann dann wieder ein LAN-auf-RS485 Adapter machen, oder über serielle Schnittstelle falls vorhanden. Zu einer Steuerung als embedded-Gerät (gefällt mir immer noch am besten): Sebastian hat mittlerweile eine originale günstig bei Ebay bekommen, dürfte also versorgt sein. Mit Verlaub und allem Respekt, er hätte die Hardware wohl gebaut bekommen, aber (noch) nicht die Software. Das ist nichts für das Kapitel "mein erstes C-Programm" oder "mein erstes Mikrocontroller-Projekt". Wenn auch andere was davon haben sollen ist das ein echtes Softwareprojekt. Wie ich schon weiter oben schrieb, alles was es braucht ist jemand der das machen will und kann. Weiter liegen dem keine Steine mehr im Weg, Jo und ich sind bestimmt gern behilflich. Jörg
Datum:
@Jörg vielleicht sollte ich erstmal kurz beschreiben, was mich hier so treibt... Ich habe kürzlich einen Bauernhof erworben und plane jetzt die Heizung mit einer modernen Steuerung zu regeln. Später soll das Ganze auf das gesamte Haus ausgedehnt werden, um solche Sachen wie Lüftung und Solarkollektoren einzubinden. Unter den angebotenen Heizungsregelungen habe ich nichts Tolles gefunden. Die UVR-1611 ist für das was sie kann schon ziemlich teuer, in meinen Augen aber auch schon veraltet. Ich hätte gerne einen Netzwerkzugang (LAN), genug Speicher und Rechenleistung für alles mögliche und natürlich die Vernetzung von Sensoren und Aktoren. Die C-Controls kommen meinen Ansprüchen schon am nächsten, da fehlt aber die Netzwerkanbindung. Ich habe mich mal nach den Alternativen für solch eine zentrale Steuereinheit umgesehen. So richtig begeistert hat mich nichts. Da gibt es zum Einen die Leute, die kommerzielle Hardware verwenden und für wenig Geld einen Controller mit wenig I/Os bekommen. In 6 Monaten gibt es das Ding dann nur noch bei Ebay. Andererseits gibt es viele Miniaturplatinen mit Controllern drauf. Zum Beispiel von Atmel... auch die werden nicht langfristig erhältlich sein. Da ich keine Lust habe bei NULL anzufangen, sollte schon eine Menge Software da sein, damit man schnell auf die Beine kommt. Ich stelle mir ein 32bit System mit Linux vor, und einer aktiven Nutzergemeinde. Das ganze sollte dann auch noch einfach und bezahlbar auf die Platine zu bringen sein. Das einzig mir bekannte System, das meines Erachtens diese Anforderungen gut erfüllt, ist der Blackfin BF536. Ein großes SDRAM dran, booten aus einem kleinen seriellen Flash. Danach auf einer SD-Karte weiter. Müßte man eigentlich in ein recht kleines Hutschienengehäuse reinbringen können. Was für Gehäuse von Bopla verwendest Du denn? Was die Steuersoftware angeht, die auf einem solchen System läuft, hat natürlich jeder andere Vorstellungen. Ich denke aber, das als erster Schritt PAWN eine ganz gute Grundlage wäre und man darauf sowohl auf Textbasis als auch grafisch per Konverter aufsetzen kann.
Datum:
@Wolfgang: Mir ist noch nicht klar, was von alldem du eigentlich mit PHC machen willst. Das System eignet sich für Schaltaufgaben und zum Stellen, für Sachen mit Meßwerten so wie es im Moment ist eher nicht. Von PEHA gibt es ein Analogmodul und Dimmer, da kann man Werte setzen sowie bei ersterem eine Regelung einschalten, mehr ist mir nicht bekannt. Naja, am Busprotokoll scheitert es nicht, wenn sowohl Steuerung wie Module was eigenes sind kann man natürlich andere Dinge tun. Allerdings nicht "kompatibel". Der Hersteller PEHA will da auch mal hin, in Richtung Meßwertverarbeitung, aber noch ist es nicht soweit. Die Sprache PAWN kenne ich nicht. Scheint für "klassisch" sequentiellen Programmablauf zu sein. In so einer Steuerung passiert aber alles parallel, jedes Eingangsevent kann zu jeder Zeit kommen und soll etwas auslösen. Da gibt es kaum Programmfluß, sondern Reaktion auf Ereignisse und Auswertung von Bedingungen. Wenn man es in einer Sprache ausdrücken will (statt grafischem Drag+Drop von Regeln/Makros wie zur Zeit), dann kommt eher was in der Art einer HDL-Sprache in Frage (VHDL, Verilog, aus der Ecke). Oder eine SPS, denn sowas ist die Anlage im Grunde. Ich verwende Gehäuse der Combinorm/Combicontrol-Reihe von Bopla. Kann ich grad nicht genauer nachschauen, deren Site ist überlastet.(!?) Es gibt leider kein längeres als ich für die Ausgänge verwende. (4TE, es gibt noch 2TE und 1TE.) Jörg
Datum:
@Jörg, danke dass Du mich auf die fehlende Analogfunktion in PHC aufmerksam machst. Das ist ja echt nicht in meinem Sinne.... hatte ich nicht gedacht. Mit der Sprache hast Du recht. Ich habe bloss das Gefühl, dass für komplexere Schaltvorgänge die prozedurale Form die leistungsfähigere ist. Bin noch echt unentschlossen, was ich machen werde...
Datum:
Das ist ein sehr interessantes Projekt
Eine mögliche Idee ist, eine Software-Steuerung auf einem Open-Source Router laufen zu lassen, oder anderen Linux-fähigen always-on Gerätschaften die sich im Hause finden. Den Übergang auf den "echten" Modulbus kann dann wieder ein LAN-auf-RS485 Adapter machen, oder über serielle Schnittstelle falls vorhanden. |
Ich denke www.fli4l.de waere eine super Basis als open Source Router fuer die Software-Steuerung. Bin schon sehr gespannt, wie es weiter geht. Jens
Datum:
Ich dachte auch an eine Display_Lösung nach, wenns is, kann ich gerne den Layout-Part übernehmen...
Datum:
@Jens: zurücklehnen gildet nicht, nur Mitmachen bringt uns voran! @Frank: (nein, eher für die Allgemeinheit, bin mit Frank schon per PM in Kontakt) Ein Display steht häufig auf der Wunschliste, haben schon mehrere im Auge. Protokolltechnisch gibt es da ein paar Besonderheiten, wegen des "zentralistischen" Aufbaus. Von Peha gibt es ein Display, das wird mit einer seperaten RS485 an die Steuerung angeschlossen. So hat es alle Möglichkeiten. Will man ein Display an den Modulbus anschließen, dann muß es z.Zt. eine Anzahl Ein/Ausgänge "emulieren", die man in der Steuerung entsprechend programmiert. Die Darstellung ist natürlich Privatsache des Displays. Wie man die da reinbringt steht noch auf einem anderen Blatt.
Datum:
Wo kann man denn als Privatperson die Bopla CombiNorm-Control Hutschienen Gehäuse kaufen?
Datum:
Wer braucht denn wieviele Gehäuse? Da wir eine Platinen-Sammelbestellung machen wird das mit den Gehäusen auch wieder Thema, die sollte man auch gesammelt bestellen. Das letzte Mal habe ich die Gehäuse von Bopla direkt bezogen.
Datum:
Wollen wir mal hier weitermachen, statt in dem überholten Sammelbestellungs-Thread? Beitrag "Hat jemand Interesse an Platinen für das OpenHC Projekt?" Was Sven beschreibt ist ziemlich genau die Original-Steuerung. Wie funktioniert die: Es wird eine 32 KiB große Tabelle von der PC-Software in die Steuerung übertragen. Darin ist ziemlich kompakt die ganze Wenn-Dann Mimik kodiert, mit einer Art Compiler aus dem erzeugt, was der User sich so zusammengeklickt hat. Der Aufbau dieser Tabelle ist größtenteils oder gar komplett entschlüsselt (nicht von mir). Es gibt auch noch Uhren als Ereignisse, sowie Displayausgaben auf der Reaktionsseite. Zur Frage, warum macht das keine Linux-Kiste im Nebenjob: Ich würde den Code so schreiben, das er sowohl in einem Embedded-Gerät als auch in einem PC laufen kann. Auch ein offener Linux-Router ist eine interessante Zielplattform. Für PC oder Router braucht man dann aber eine RS485-Schnittstelle, halbduplex, mit fixer Umschaltung zwischen Senden und Empfangen (innerhalb ~3 Bits). Recht elegant ist ein Netzwerkadapter, dann geht das von überall. Ich habe einen Xport485, der schaltet aber wohl zu langsam um. Für die Betriebssicherheit finde ich eine dedizierte Embedded-Kiste besser. Die ist viel weniger komplex, hat mehr Chancen 24/7 absturzfrei zu laufen, braucht nicht mehr Resourcen als nötig. Ein ATMega128 reicht aus, drei serielle Schnittstellen sollten dran sein (Modulbus, PC-Interface, und noch ein Bus der mehrere Steuerungen verbindet). Ein SD-Slot wäre vielleicht noch ein nettes Gimmick, um die Programmierung zu Fuß zu übertragen. Jörg
Datum:
Also ich fürchte das wird wieder so ein Teil wo alles soll, Display,Tasten,USB,SD-Card und dann noch eine 3.Schnittstelle zum vernetzen mit weiteren Steuerungen ;-) und endet so wie jedes andere Hausbusprojekt hier. Ich dachte da an etwas einfacheres: Atmega128, 2 Leds, 2 RJ12-Buchsen und Hühnerfutter. Angenommen man will das ganze mit einer anderen Steuerung verbinden, so nimmt man das gleiche Modul nochmal programmiert es anders und hängt es auch in den RS485-Bus. SD-Karte würde ich dann an einer übergeordneten steuerung reinstecken. Sei es ein "openwrt-router" oder z.B. auch so ein "selbstbau hutschienen Webserver". Ich habe folgendes Ziel: Ich habe einen Router, der alles steuern soll. Aber der ist mir halt nicht genügend embedded. Wenn sich die Linux-Kiste mal aufhängt soll trotzdem noch der Lichtschalter funktionieren. Dies gelingt wenn die Steuerung von einem AVR gemacht wird. Der ist aufjedenfall so programmierbar das nichts abstürzt.... @ Jörg Hohensohn Ich kenne den Aufbau des 32k Files nicht, kann ich mir das eher vorstellen wie ein AWL-Programm einer SPS oder eher wie eine "Kreuzmatrix" (Verknüfungsregeln) Wäre es vorstellbar sowas auch ohne lcd zu implementieren. Wäre shcon cool wenn das mit der orginalsoftware funktionieren würde ;-) Mfg Ulrich
Datum:
Ulrich wrote: > Also ich fürchte das wird wieder so ein Teil wo alles soll, > Display,Tasten,USB,SD-Card und dann noch eine 3.Schnittstelle zum > vernetzen mit weiteren Steuerungen ;-) und endet so wie jedes andere > Hausbusprojekt hier. Kommt drauf an ob man lieber redet als macht... ;-) Die bisherigen Teile von OpenHC funktionieren, und zwar 24/7 bei mir seit 3 Jahren, mittlerweile auch bei etlichen anderen Leuten. Es ist eine universelle Lösung, kein Spezialgefrickel was nur die Feature-Notwendigkeiten des Entwicklers abdeckt. Zugegeben, es ist nicht hier als Community-Projekt entstanden (dieses Forum kannte ich damals noch nicht), sondern im Alleingang. Mit den Features stimmen wir doch fast überein. Das mit der SD-Card habe ich ja selber als Gimmick bezeichnet. Die dritte Schnittstelle muß man ja nicht gleich inbetrieb nehmen. Dafür fehlt uns auch noch die Erfahrung, denn für den Hausgebrauch reicht eine Steuerung, so ein System hat niemand. > Ich dachte da an etwas einfacheres: > > Atmega128, 2 Leds, 2 RJ12-Buchsen und Hühnerfutter. Kann man machen. > Angenommen man will das ganze mit einer anderen Steuerung verbinden, so > nimmt man das gleiche Modul nochmal programmiert es anders und hängt es > auch in den RS485-Bus. Darüber sollten wir nochmal reden... Die Steuerung hat hier eine zentrale Rolle, daher fragt man aus verschiedenen Gründen besser die. > @ Jörg Hohensohn > Ich kenne den Aufbau des 32k Files nicht, kann ich mir das eher > vorstellen wie ein AWL-Programm einer SPS oder eher wie eine > "Kreuzmatrix" (Verknüfungsregeln) Es ist zunächst eine indizierte Liste, bei welchen Events welche neuen Nachrichten ausgelöst werden sollen. Dazu kommt die Initialisierung, wie die Module konfiguriert werden, z.B. welche Events sie überhaupt senden sollen. Und die Konfiguration der Uhren. > Wäre es vorstellbar sowas auch ohne lcd zu implementieren. Wäre shcon > cool wenn das mit der orginalsoftware funktionieren würde ;-) Ja. Es gibt (gab) die Steuerung auch ohne LCD. Ich würde erstmal mit einem RS485-Konverter und einem PC anfangen. Darauf die Software "controllerfreundlich" entwickeln und debuggen. Dann ins Zielsystem. Man muß nicht als erstes Hardware bauen. Jörg
Datum:
>> Aber das nur am Rande, vermutlich will niemand seine >> Haus-Steuerung einem Windows-PC überantworten? Wollen Sie das Licht wirklich ausschalten? [Ja] [Nein] [Abbrechen] Auf welche anderen Bussysteme ließe sich das noch anwenden, wenn man die Protokolle entsprechend implementiert. Randbedingungen wäre ja wohl: 24 Vdc Versorgung, RS485 bidirektionale Schnittstelle. Mich würd das schon interessieren, mache gerade E-Planung für einen Neubau EFH. Ich hab nur - außer Heizungssteuerung - bisher nichts gefunden, wo es wirklich sinnvoll einsetzbar wäre... ;-) Also die Legitimation fehlt noch ein bißchen.
Datum:
habe mal eine Frage: Angenommen ich bin Elektriker und baue einem Kunden so eine selbstbau Steuerung ein, würde mich dann auch das Elektroschrottgesetzt treffen und ich müsste das Gerät registrieren lassen?
Datum:
Angehängte Dateien:Nach 4 Tagen rumlöten habe ich nun mein "Development Kit" fertiggestellt. ( Es besteht aus 4 x Atmega8 und 1 x Atmega162(2UART) ) Als nächstes muss ich den bootloader zum laufen bekommen.... Mfg Ulrich
Datum:
Sieht sehr gut aus! Lass' mich raten was das jeweils ist... 4 Busteilnehmer, und aus dem Mega162 baust du dir einen RS232/485 Konverter? (Eine Steuerung ja wohl nicht.) Falls du von meinem Bootloader sprichst: Die PC-Software zu selbigem ist darauf ausgelegt, durch eine Peha-Steuerung mit den Modulen zu reden. So direkt verstehen die sich nicht, das Protokoll ist Steuerungsseitig anders. Ich hatte das zwar mal für Direktanschluß, aber das war recht unbequem, man mußte für ein Update die Steuerung und Originalkomponenten vom Bus nehmen. Deshalb gibt es jetzt den Bootloader v2.0. Man könnte die Update-PC-Software allerdings wieder dahinbringen, das ist schon teilweise vorgesehen. Zum Entwickeln braucht man den Bootloader übrigens nicht, da ist er sogar eher hinderlich. Einfach weglassen, die Fuses auf normale Startadresse 0 stellen. Per ISP-Stecker kriegst du die Software viel schneller rein. Nimmt man einen Mega88 statt dem Mega8, dann geht auch Debugging im Zielsystem, mit DebugWire. Von wegen Elektroschrott: greift meines Halbwissens nach für Haustechnik glücklicherweise nicht. Solche Komponenten werden nicht als eitgenständige Geräte betrachtet. Jörg
Datum:
Kurze Fragen zu den UP-Eingangsplatinen: Kann mann die UP-Eingangsplatinen mit den "normalen" PHC Modulen betreiben? Wo kann man die fertigen Platinen beziehen? MfG Markus
Datum:
Markus K wrote: > Kurze Fragen zu den UP-Eingangsplatinen: > Kann mann die UP-Eingangsplatinen mit den "normalen" PHC Modulen > betreiben? Klar, das ist ja der Witz dabei. > Wo kann man die fertigen Platinen beziehen? Bei mir.
Datum:
Ich habe jetzt mal versucht ein ganz eigenes Protokoll zu erfinden(aber Hardwarekompatibel). Seit 2 Wochen 24x7 bin ich dran und noch lange nix spruchreifes rausgekommen. Ich habe vor 2 Wochen mit Java angefangen und habe damit ein Flashprogramm geschrieben..hat dank viel copy past und dem coolen Eclipse sogar funktioniert. Ich habe mir auch schon angeschaut wie man GUIs mit JAVA macht, aber dass bekomme ich bei weitem noch nicht auf die Reihe deshalb folgende Ausschreibung ;-) : Ich suche jemanden der rein zufällig eine Schicke GUI programmieren kann ;-) Das Programm sollte folgendes können: -Drag'n'Drop UND, ODER, Zeitglieder usw frei platzieren und verbinden -graphischer "state maschine Editor" habe bei google winfact gefunden. Kein schlechtes Vorbild ;-) -und das Ergebnis dann als XML speichern ;-) Wer meldet sich? Mfg Ulrich
Datum:
>folgende Ausschreibung
wieviel zahlst denn ;-)
Datum:
kommt aufs Ergebnis an ;-) aber 20Euro und eine Flasche Bier sind drinn ;-) Mfg
Datum:
Ulrich wrote: > Ich habe jetzt mal versucht ein ganz eigenes Protokoll zu erfinden(aber > Hardwarekompatibel). > Seit 2 Wochen 24x7 bin ich dran und noch lange nix spruchreifes > rausgekommen. Was ganz eigenes, schade, muß das? Warum nicht das bestehende weitertreiben? Kompatibilität hilft, Wegwerfcode hilft nicht. Da steckt bereits viel Arbeit drin, viele Probleme sind schon gelöst. ;-) Das Datenformat für die Ereignistabelle der Steuerung ist uns bekannt, auf Anfrage hättest du das bestimmt bekommen, und mit 2 Wochen Arbeit wäre eine nette embedded-Codebasis dafür auch im Bereich des Möglichen. Jörg
Datum:
Hallo Wie funktioniert der Adapter? Gibt es einen Treiber, der eine Windows-COM-Schnittstelle auf das LAN umsetzt, damit eine Software, die RS232 erwartet, auf das Ethernet umgeleitet wird? Gruß, DN
Datum:
dn schrieb: > Wie funktioniert der Adapter? Gibt es einen Treiber, der eine > Windows-COM-Schnittstelle auf das LAN umsetzt, damit eine Software, die > RS232 erwartet, auf das Ethernet umgeleitet wird? Ja, ganz genau. Es wird ein "virtueller COM-Port" eingerichtet. Lantronix hat sowas für ihre XPorts, andere Firmen für ihre Lösung. Unter Linux nimmt man "socat". Jörg PS: ich habe noch reichlich von den fix+fertig bestückten+programmierten UEM-Platinen, Selbstkostenpreis 19,17€.
Datum:
Hallo Herr Hohensohn Die Platinen, die Sie ansprechen, sind das die RS232-Ethernet-Platinen? Hätten Sie auch noch das passende Hutschienen-Gehäuse dazu? Was würde das ganze dann mit Versand kosten? Mit besten Grüßen, dn
Datum:
Hallo, ich hatte schon lange nach einer Softwarelösung gesucht, mit der ich meine alte PHC-Steuerung mit einem kleinen Linuxrechner steuern kann (z.B. über's Web, aber z.B. auch, damit die Rolläden zu Sonnenauf- und untergangszeiten in Bewegung kommen [per Perl-Script]). Jetzt finde ich das Programm phc_cmd und bin ganz begeistert, das man damit eine direkte Steuerung durchführen kann. Leider liess sich der Sourcecode unter Ubuntu 9.04 nicht compilieren, die Binaries funktionieren aber. Die Hilfe mit der Befehlsfolge 40 01 06 hat mich soweit gebracht, das sich etwas bewegt hat. Klasse. Gibt es eine Liste der Befehle mit der ich drei AMD Module mit 8 Kanälen ansprechen kann? Ich hätte vermutet, das in der Befehlsfolge "Module, Kanäle und Funktion" hinterlegt sind. Durch einfaches probieren habe ich aber keine Logik dahinter erkennen können. Roland
Datum:
@dn: nein, ich sprach von den runden Unterputzplatinen. @roland: Na, das ist doch prima. Warum mag phc_cmd nicht kompilieren? VOn wegen der möglichen Befehle: melde dich doch mal an und schick' mir eine PN. Was auch sehr hilft ist, das Programm "phc_log" in Betrieb zu nehmen. Braucht nur einen Draht und Masse vom PHC-Modulbus zum COM-Port des PC. Die Logik für das Ausgangsmodul ist im 3. Byte obere 3 Bit Kanalnummer, untere 5 Bit Funktion. Wenn ein Kanal eine Zeit erfordert kommt die noch hintendran, 2 Byte little endian. Jörg
Datum:
Hallo Jörg, mit Interesse habe ich mir dein Projekt angesehen. Leider konnte ich keinen Hinweis finden, was für Bauteile Du verwendet hast. Ich wollte zunächst mal mit dem Ausgangsmodul Relais starten. Kannst du mir verraten, was für ein Relaistyp verwendet wurde und ggf. wo der zu bekommen ist? ggf weiß ja auch jemand anderes einen Rat?? Gruß stefan
Datum:
Hallo allerseits, ich hoffe das hier nochmal jemand reinschaut. Erstmal danke für die fleisigen Entwickler. Gerne würde ich dazu auch noch was beitragen. Mein Ziel einen Dimmer für dieses System zu bauen. Dazu könnte ich noch was hilfe gebrauchen, in Richtung Software. Falls es jemanden einfach fällt die Software für das Basismodul so umzuschreiben, das im Speicher eine Variable liegt die, die Helligkeit angibt, kann ich eine Hardware fürs Dimmen entwickeln und den Microcontrollercode so anpassen, das diese nutzbar ist. Hier wäre dann alles möglich Phasenanschnitt, Phasenabschnitt, Tiefsetzstellermode für Kleinspannung z.b. für LED beleuchtung oder auch eine analoge Ausgangsspannung zum Dimmen für EVG für Leuchtstofflampen. @ Stefan, falls es noch aktuell ist, hier bekommst du passende Relays http://de.mouser.com/Search/Refine.aspx?Keyword=RT114024 Gruß Christoph
Datum:
Hallo könnt ihr mir helfen das forencity Forum für Phc ist offline Weiß jemand ob es Ersatz gibt?
Datum:
gibt es die Layouts und Bestückungspläne auch zum Download?




