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/

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!

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

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.

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.

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.

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.

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.

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

@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

@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.

@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

@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...

Ich dachte auch an eine Display_Lösung nach, wenns is, kann ich gerne 
den Layout-Part übernehmen...

@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.

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.

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

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

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

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.

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

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€.

@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

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