Vorstellung - ich bin der mit OpenHC

Frohes neues Jahr,

vor einer Weile habe ich ganz zufällig gesehen, daß es wieder ein PHC-Forum gibt. Dann war ich hier ein bischen "Lurker", nun habe ich mich angemeldet.
Im alten foren-city hatte ich mich mit dem anmaßenden Nick "Busmaster" angemeldet, hier nun mit meinem normalen Alias.

BTW, das alte Forum kann man noch im Internet Archiv betrachten, letzter funktionierender Snapshot vom 26.6.2010:
web.archive.org/web/20100626110951/http://phc.foren-city.de/

Seinerzeit hatte ich mir die Open-Source Alternative "OpenHC" gebaut, eigene Komponenten und viel Reverse Engineering. (So bin ich auch fast unabhängig von der Honeywell-Abkündigung.) Die funktionieren auch zuverlässig, über die Jahre habe ich ein oder zwei Relais getauscht, die Firmware ist schon lange stabil. Das Haus tut was es soll, ich habe mich anderen Themen gewidmet.
Dank Änderungen bei Sourceforge ist dort das Wiki verlorengegangen, die Projektseite nur noch rudimentär:
sourceforge.net/projects/openhc/
Bevor Fragen kommen: Man könnte die Module heute nicht mehr so fertigen, weil Bopla die schönen Hutschienengehäuse der Serie "CombiNorm-Control" m.W. nicht mehr verkauft.

Ein paar Komponenten habe ich bei Ebay noch aufgesammelt, um damit mal "irgendwann" was zu machen, sie genauer zu untersuchen: So ein altes Display (leider von der neuen Software nicht mehr unterstützt), ein MCC (leider nur von der neuen Software unterstützt), ein STMv3. Mittlerweile habe ich auf letzteres und die neue Software umgestellt.

In letzter Zeit habe ich mich ein bischen mit IoT beschäftigt (auch beruflich), bin gerade dabei eine Art Gateway von PHC auf MQTT zu schreiben, damit wäre das System dann offen für externe Dinge.

Soweit erstmal, viele Grüße
Jörg

Hallo Jörg,

willkommen im Forum.
Schön, wenn sich die "alten" Cracks im neuen Forum so allmählich versammeln. Das beruhigt mich doch etwas angesichts der Abkündigung von PHC seitens Honeywell!

MQTT Gateway hört sich gut an...

Schöne Grüße
Ansgar

Hallo Jörg,


schön, dass Du auch den Weg hier ins Forum gefunden hast.
Deine Sourcen zu OpenHC waren mir oftmals eine Hilfe bei der Implementierung meines PHC-MQTT-Gateways.
Was genau hast Du denn vor? Mein Gateway kommuniziert mit der V2-Steuerung über die normale RS232 Schnittstelle oder IP-RS232-Gateway. Darüber kann ich dann Ausgangsmodule über MQTT ansteuern, kann Eingangsbefehle emulieren und bekomme aber auch Änderungen der Eingänge und Ausgänge (falls möglich) mit. Das System läuft seit langem recht stabil auf einem RPi (auf Windows läuft es auch). Es sind nicht alle möglichen Module implementiert (ich habe nicht alle verfügbar), aber es ist eigentlich ein leichtes, die Modul nachzupflegen, wenn man Testen kann.

Gruß
Andreas

Danke für die Anteilnahme!

DIe Idee hinter MQTT ist, Visualisierung oder Spielereien wie "Google/Alexa, mach das Licht an" hinzubekommen. Wie genau ab MQTT weiter weiß ich zugegeben auch noch nicht. Aber erscheint mir ein als ein guter Interface-Level, damit können "alle" ewas anfangen. Auch kleine Embedded-Platinchen ohne Linux, a'la Espressif.
Zum Fachlichen mache ich wohl besser einen separaten Thread auf.

Die PHC-Abkündigung beeindruckt mich wie gesagt nicht sonderlich. Stiefmütterlich behandelt haben sie es schon immer...
In der Praxis finde ich es nicht so entscheidend, was man für ein Bussystem hat, Hauptsache man hat überhaupt eines. Mit entsprechendem Interfacing kommt man dann weiter zu anderer Technik, ist weniger herstellerabhängig.

Grüße
Jörg

Hallo Andreas,

Andreas schrieb:

Deine Sourcen zu OpenHC waren mir oftmals eine Hilfe bei der Implementierung meines PHC-MQTT-Gateways.
Was genau hast Du denn vor? Mein Gateway kommuniziert mit der V2-Steuerung über die normale RS232 Schnittstelle oder IP-RS232-Gateway. Darüber kann ich dann Ausgangsmodule über MQTT ansteuern, kann Eingangsbefehle emulieren und bekomme aber auch Änderungen der Eingänge und Ausgänge (falls möglich) mit. Das System läuft seit langem recht stabil auf einem RPi (auf Windows läuft es auch). Es sind nicht alle möglichen Module implementiert (ich habe nicht alle verfügbar), aber es ist eigentlich ein leichtes, die Modul nachzupflegen, wenn man Testen kann.

gibt's dein MQTT Gateway irgendwo frei verfügbar?

Hoi mein Meister,
schön mal wieder von dir zu hören. Hoffe alles klar bei dir.
Die Zeit rennt - wir leben jetzt schon über 10 Jahre in unserem OpenHC-Haus.
Die Abkündigung von Honeywell macht mich auch nicht wirklich nervös, solange noch Jungs wie du, simonjo, .. dabei sind.
Ein Kollege hat vor kurzem AMD-Module gefertigt (danke für deinen Relais-Haltestrom-Support) und ist jetzt an Eingangsmodulen.
In meinem Dunstkreis gibt es mittlerweile 4 OpenHC -Häuser

Dennoch plagen mich 2 Dinge:

1 .)
Ich habe mir mit node-red und dem xphcextc-binary von simonjo auch einen MQTT-Gateway für den raspberry gebastelt.
D.h. ich kann via MQTT beliebige Eingänge pollen und Ausgänge schalten. Um Events von PHC nach node-red zu kommunizieren, muss ich allerdings jedes Event als Action-URL in PHC definieren. node-red empfängt via Socket und stellt die Events dann via MQTT-Brocker zur Weiterverarbeitung zur Verfügung.
Lass es mich bitte wissen, wenn du eine Alternative hast.

2.)
ich würde wahnsinnig gerne das Thema LED-Dimmer angehen. Platinendesign und Produktion könnten wir machen. Aber wir würden deine Expertise für Schaltungdesign und Firmware benötigen. Hättest du Interesse?


Gruß
Michael aus Stuttgart

Hallo Michael und Welt,

ich mache außer sehr gelegentlichen Konfigurationsänderungen nichts mehr aktiv an der Anlage, funktioniert zufriedenstellend.

MQTT brauche ich auch nicht wirklich, aber das würde ich wohl am ehesten wiederaufnehmen. Kann den Code ja mal posten oder bei Github einstellen. Status von der Anlage nach MQTT funktionierte, bisher nur Steuerung V3 über Netzwerk, die älteren über RS232 ist aber auch im Prinzip vorgesehen. Ich war entscheidungsschwach an der Stelle steckengeblieben, wie ich denn die umgekehrt gerichteten Kommandos benennen sollte. Dafür ist MQTT imho ursprünglich nicht gedacht, es sammelt Zustände von verteilten Clients ein, sowas wie Messwerte.

Das mit dem (RGB) LED-Dimmer hatte Jo auch schon mal aufgeworfen, ich selbst habe keinen Bedarf. Es gibt bei den OBO-Modulen wohl einen Quad-Dimmer, dessen Programmierung könnte man dafür mißbrauchen. Wir können uns zwar beliebige Module ausdenken (wie z.B. meinen anlernbaren Infrarotempfänger), aber um sie mit der Original-Autorensoftware bedienen zu können muß man das irgendwie auf vorhandene Module abbilden.
Was soll dein Dimmer denn können? Aber rechne nicht wirklich mit mir, so viele andere Projekte...

Viele Grüße
Jörg

Hallo Jörg,
danke für die Rückmeldung.
Schade, dass dich der Dimmer-Schuh nicht drückt:)
Ich habe das Problem, dass ich sehr viele 12V Halogenleuchten verbaut habe. Die Leuchten und das zugehörige Netzteil sind mit einer HaloX-Box in die Decke integriert und werden mit Peha Phasenabschnittdimmer angesteuert. Soweit so gut.
Ersetzte ich aber die 12V Halogenleuchte durch eine LED-Leuchte dann kommt beim Herunterdimmen Discostimmung auf.
Habe schon verschiedene LED-Leuchten und Netzteile getestet - will einfach nicht. Bin jetzt nicht der Fachmann, aber Abschnittdimmer mit nachgeschaltetem Netzteil scheint wohl nicht geeignet zu sein, um 12V LEDs zu dimmen.
Mein Ansatz wäre gewesen:
* ordentliches 12V Netzteil im Schaltschrank
* Elektronik-Platine mit PHC-Busanbinung und 12V PWM-Treiber, der dann über die bestehende 220V Leitung zur Lampe dirket das LED-Leuchtmittel getaktet mit 12V versorgt.
Da du ja raus bist werde ich mal einen Peha-Dimmer aufschrauben und mal checken, ob ich die Info über die Helligkeit  irgendwie elektronisch abgreifen kann (Steuerspannung am Triac oder so) um so die PWM anzusteuern.

Zu MQTT - dein Angebot den Code bei github zur Verfügung zu stellen gefällt mir. Ich räum dann mal meine Node-Red/xphcextc- Bastelei auf und ziehe nach.

Jetzt noch eine Verständnisfrage an die PHC-MQTT-Gemeinde hier:
Über Netzwerk (rs232) können "nur" Ausgänge, LED-Rückmeldungen und Eingänge geschaltet bzw. abgefragt und Action-URLs empfangen werden.
Wenn ich aber von meinem PHC-System beliebige Events via MQTT verarbeiten möchte, braucht es einen rs485-Sniffer (wie das betagte phc_log-Programm von Jörg) das am rs485-Bus horcht, das Protokoll auswertet und für die MQTT-Anbinung aufbereitet.
Liege ich hiermit richtig?
Hat jemand einen solchen Sniffer oder eine Alternative zuverlässig am Laufen?

Gruß und Dank
Michael

Hallo Michael,

wenn du Pech hast, macht das Dimmermodul den Phasenschnitt in Software, per Timer nach Nulldurchgangserkennung. (So würde ich es machen.) Dann gibt es keine interne Steuerspannung oder so.
Es gibt/gab diese Analogmodule, aus PHC-Sicht das gleiche wie ein Dimmer, aber die erzeugen eine 0...10V Steuerspannung. Das könnte man nutzen, um mit einem geeigneten Vorschaltgerät den LED-Strom (nicht Spannung!) vorzugeben. Sie waren damals für elektronische Verschaltgeräte von Leuchtstofflampen gedacht.

In meinem Haus habe ich nur wenige Dimmer. Das lohnte damals die Eigenentwicklung nicht, ich hatte ein paar gekauft. Zusammen mit der Steuerung meine einzigen Originalteile.

Zu deiner RS232-Frage: Man kann an der Schnittstelle nicht nur Aktionen auslösen (Opcode 0x22) und auf IO-Änderungen "subscriben" (0x20), sondern auch sowas wie eine Modulüberwachung konfigureren (Opcode 0x1A). Dann kommen alle Events des Moduls auch als RS232-Paket raus. Ich hatte damals ein geliehenes Display belauscht und das gefunden, wenn ich recht erinnere arbeitet die Visualisierung auch damit, Jo's Zeug ebenso. In den Details stecke ich jetzt grad nicht drin.

Grüße
Jörg

Hallo zusammen,

Zum Dimmen von LED-Bändern per PHC setze ich seit einiger Zeit bereits ein PHC-Funkmodul (D941 FU C) und Eltako Dimmer (FRGBW71L) erfolgreich ein. Der Dimmer liefert 4 Kanäle und steuert aktuell 2 Paulmann LED-Bänder (24V) an. 24V Netzteil ist separat nötig.

Das Einlernen war am Anfang etwas frickelig und man muss den Dimmer ebenfalls konfigurieren, aber jetzt funktioniert es zu meiner Zufriedenheit. Rückmeldung nach PHC habe ich (noch) nicht umgesetzt bekommen. Aber ich habe mich datum auch nicht weiter gekümmert.

Falls Interesse besteht kann ich die Umsetzung mal näher erläutern.

Schöne Grüße
Ansgar

Hallo Jörg,
ich denke du hast Recht mit der Ansteuerung. Bin aber dennoch optimistisch.
Mein Plan wäre eine 12/24V-Leistungsplatine zu machen, die dann die vorhandene 220V-Leistungsplatine des Dimmermodules ersetzt.
Jetzt müsste halt noch ein Atmel mit auf die untere Leistungsplatine, welcher der der Peha-Controller-Platine den Nullduchgang mit 100Hz vorgaukelt, die Zeiten des Einschalt-Signales vom Peha-Controller bestimmt und ein entsprechendes PWM-Signal mit ca. 500Hz für die Leistungsstufe erzeugt.
Sollte doch machbar sein, oder?
Werde mir die Tage mal die Signale der 5 Leitungen zwischen Peha-Controller- und Leistungsplatine an einem Peha-Dimmermodul mit dem Oszi ansehen.
Vielen Dank erst mal.
Gruß Michael

Hallo Ansgar, vielen Dank für dein Angebot. Da ich ja recht viele Dimmer verbaut habe, halte ich erst mal an der obigen Variante fest. Falls ich dann doch scheitere, komme ich gerne auf dein Angebot zurück.
Gruß Michael

Hello,
It's been a while but here we are with some news on Phc2Mqtt, maybe I should make a new topic for it.

At this moment I have a running prototype as shown in the pictures, you can just connect it in the module bus of your PHC installation.
It is mainly targetted at installations using an STMv3, but it also works with STMv1/v2

It does following:
- connects to your WLAN
- connects to an MQTT broker
- monitors the RS485 bus and sends events and status as an MQTT msg to the broker (like xphclogd)
- you can send module commands to it as an MQTT msg, and it will send it to your STMv1/v2/v3 (like xWRC)
- there is also a webconsole so you can see what is happening via a webpage

People using xphclogd will remember that we need to know which modules are used in your PHC system (the module list) so we can correctly decode packets from the module bus (RS485). We also need this info to encode commands in the correct format for the target module.

In my approach I use the PEHA System SW v 3.x.y (in which you define your project) to get the needed info, you just need to enter the IP address of the Phc2Mqtt module iso the STMv3 IP address, and then transfer the project. Phc2Mqtt will act as an STMv3 and extract the needed info.

For systems with an STMv1/v2 the workaround is to make a new project with the System SW v3.x.y that has the same modules as in your System SW v2.x.y. Also you need to make the STMv1/v2 reachable over IP with an IP-to-RS232 convertor, just like you would do for xWRC

 

Hi Jo,

wow looks/sounds really amazing!!!
When will prototypes be available for purchase?

BR
Michael

Hallo Ansgar,

die Verbindung zwischen dem Funkmodul und den Eltako-Dimmern würde mich interessieren!
Könntest Du das genauer erläutern?

gruss / vielen Dank
    Stefan