Anbindung an openHCAN

[CoolTux]

Probiere mal bitte

[GU!DO]

So, wie war das noch mit dem blinden Huhn...

Habe den HEX String in doppelte Anführungszeigen gepackt, da er sonst meinte, er müsse den "\" Escapen. Im Dump sah das dann  so aus:

$VAR1 = 'Write: \\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00';

Jetzt  sendet er 16 Bytes.

[CoolTux]

Auf die selbe Idee bin ich auch gekommen. Hab ich im File oben so angepasst. hihi

[CoolTux]

Also in Version 0.0.25 schreibt er nun alle 30s ein keepalive und empfängt an sonsten die Daten über die Read. Korrekt?

[GU!DO]

Hab mir Grad Deine Datei angesehen.

Das unterschiedet den Wissenden vom Anfänger. Du machst das dann mal einfach so...

Hattest du sonst noch was geändert?

Ich überlege schon seit längerem, wie man das Ganze am besten in Module gießt.

Das System sieht folgender Maßen aus:
Jedes Device ist einer oder mehreren Gruppen zugeordnet.
Die Gruppen sind Device Spezifisch. Wenn also z.B. eine Gruppe 70 Powerport geschaltet wird, reagieren nur die Powerport Devices, in deren Gruppenkonfiguration eine 70 eingetragen ist. Ein Rolladendevice, welches evtl. ebenfalls auf Gruppe 70 konfiguriert ist, nicht, sondern erst, wenn Rolladen 70 gesendet wird.


Folgende Geräte die am Bus betrieben werden, wären IMHO in FHEM interessant:

Aktoren
Powerports (die steuern einfach nur ein Relais, welches z.B. eine Lampen einschatet)
Rolladen (2 Relais, EIN/AUS und Richtung werden vom Controller gesteuert. 100%=ganz hoch. Würde dann z.B. mit Position-Set 100 angestoßen werden)
Heizungs-Stellmotor: im Prinzip wie der Rolladen 0-100%

Sensoren
Tempsensor liest Temperaturen aus DS1820 Temperatursensoren
Reedkontakt ueberwacht einen Kontakt, typischerweise ein Reed-Kontakt
Helligkeitssensor Sendet Helligkeitssensornachrichten auf den CAN-Bus


Ich hatte mir folgendes überlegt:
2 Physische Module:
1. wenn möglich mit try/catch Schleife zum mithören der Befehle auf dem Bus.
     Hex Daten werden ausgewertet, und an das jeweils Zuständige logische Device weiter gereicht
2. um Daten an den Bus zu senden
Für jedes Device ein logisches Modul, das
- die jeweiligen Parameter zur Verfügung stellt. Also z.B. Ein/Aus bei Powerport, oder 0-100% bei Rolladen & Heizung.
- die Werte der Sensoren anzeigt. Wie Temperatur, Kontakt offen/geschlossen oder die aktuelle Helligkeit


Was hälst Du davon, bzw. wie würdest Du als nächstes vorgehen?

[GU!DO]

Also in Version 0.0.25 schreibt er nun alle 30s ein keepalive und empfängt an sonsten die Daten über die Read. Korrekt?

Yep. Das ist korrekt.
Muß mich mal kurz um meine Kinder kümmern. Bin in ca. 45 Min. wieder am Rechner.

Nochmals: Vielen Dank für Deine Ausdauer!!!

[CoolTux]

Zwei physische Devices ist Unsinn. Du machst ein physisches Modul welches die Verbindung zum Bus hat und ein logisches Modul (oder 2 logische Aktor Sensor). Unterscheiden tust Du Aktor, Sensor und ob Rolladen oder Lichtschalter mit Hilfe von Attributen. subType zum Beispiel.
Wichtig ist das Du weißt wie Du Rolladenaktor, Sensoren und Aktoren(Lichtschalter) von den empfangenden Telegrammen unterscheiden kannst. Denn irgendwas wird gebraucht um das zu unterscheiden. Desweiteren wird eine einmalige ID oder was anderes einmaliges benötigt was den Aktor/Sensor beschreibt.

[GU!DO]

Ich habe sowas noch nie gebaut.

Wenn ich nur ein physisches Modul mache, verpasse ich doch während des Sendens evtl. Daten auf dem Bus.
Der Daemon sendet ja muter drauf los, dem ist doch völlig egal, ob ich grad "zuhöre" oder nicht.

Die Zuordung der Pakete habe ich mir grad angesehen.
Ich kann Anhand der Datenpakete im Hex-Format unterscheiden, welches Device mit welche Gruppe gemeint ist.

Empfangenes Hex Paket:
68 8d 10 00 04 00 00 00 05 11 46 01 3c 93 04 08
                                        ^^  ^^  ^^ ^^ 
von links nach rechts:
05 = ist die Gruppe, die erstmal am intessantesten ist, diese enthält alle Pakete zur Device Kommunikation. (z.B. Taster_Down/Up, Power_Group_On/Off ...)
        Es gibt noch weitere Gruppen, in Gruppe 01 z.B. sind Nachrichten zur Erreichbarkeit und Uptime der Controller-Bords. (Vielleicht für später interessant)
11 = Power_Group_State_Info (Hier könnte auch Power_Group_ON/OFF als Befehl kodiert mit 0a/0b stehen)
46 = Gruppe 70
01 = Status EIN / 00 = Status AUS

d.h. unsere  Lampe im Hausflur (die hängt am Powerport der auf Gruppe 70 hört) ist eingeschaltet worden.

Es gibt eine installation.xml Datei, in der man den Gruppen Namen zuordnen kann. Bei mir z.B. 70 LichtFlur.

Ich bin mir jedoch noch nicht im klaren, wie ich das am besten in FHEM Abbilde. Meine erste Idee war:

Ich habe ein Logisches Modul Lampe.
Dieses hat die Schaltzustände AN/AUS.
Bei beim Define dieses logischen Moduls lese ich alle Lampen Bezeichnungen inkl. der zugehörigen Gruppen aus der Datei installation.xml.
Dann bekommt der Benutzer eine Liste mit allen Lampen im System in den Attributen zur Auswahl angezeigt und kann sich entscheiden, welche Gruppe gesendet werden soll.

Nun sagtst Du, ein logisches Device für alle Aktoren. Aber jeder Aktor hat doch verschiedene Zustände. Ich muß also irgendwie zusehen, dass bei einer Lampe nicht Geöffnet/Geschlossen als Zustand auswählbar ist

[CoolTux]

Erstmal eins nach dem anderen.

FHEM kann senden und empfangen gleichzeitig. Das ist kein Problem.

68 8d 10 00 04 00 00 00 05 11 46 01 3c 93 04 08

Woran erkennst du am Telegramm das es deine Lampe im Hausflur ist und nicht die Lampe im Wohnzimmer?
Waran erkennst du das es eine Lampe und kein Sensor ist?
Diese Info brauchen wir erstmal. Basierend darauf unterscheiden wir dann ob Lampe oder Rolladenaktor oder Tempsensor und auch welches Device, ob Lampe Flur vorne oder Tempsensor Kinderzimmer und so weiter.

Das müssen wir erstmal klären.

[GU!DO]

Vielleicht noch etwas Grundsätzliches zum openHCAN System:
- Es besteht aus Controllern mit ATMega32 (oder 644) Prozessoren.
- Jeder Controller hat eine Adresse unter der er angesprochen werden kann, um ihn zu konfigurieren bzw. Firmwareupdates einzuspielen.
  Diese Adresse ist nur zur Wartung interessant. Im Betrieb hat sie keine Funktion.
- Jeder (meiner) Controller hat 8 physische Ein- und 20-Ausgänge. Die den auf ihm konfigurierten "logischen" Devices zugeordnet werden können.

z.B.:
Device Taster: Belegt einen physischen Eingang und kann eine logische Adresse schalten.
Device Powerport: Kann mit einem physischen Ausgang (der z.B. ein Relais schaltet) verknüpft werden und mit bis zu 5 logischen Gruppen auf die er reagiert.
Device Rolladen: Muß mit 2 physichen Ausgängen verknüpft werden (1x Relais EIN/AUS & 1x Relais Auf/AB) und hat ebenfalls bis zu 5 logisch Gruppen.
                           Welches Relais wann schaltet, regelt das Rolladen Device selbstständig.

Die Daten innerhalb der Pakete:

Empfangenes Hex Paket:
68 8d 10 00 04 00 00 00 05 11 46 01 3c 93 04 08
                                        ^^  ^^  ^^ ^^ 
von links nach rechts:
05 = ist die Gruppe, die erstmal am intessantesten ist, diese enthält alle Pakete zur Device Kommunikation. (z.B. Taster_Down/Up, Power_Group_On/Off ...)
        Es gibt noch weitere Gruppen, in Gruppe 01 z.B. sind Nachrichten zur Erreichbarkeit und Uptime der Controller-Bords. (Vielleicht für später interessant)
11 = Power_Group_State_Info (Hier könnte auch Power_Group_ON/OFF als Befehl kodiert mit 0a/0b stehen)
46 = Gruppe 70
01 = Status EIN / 00 = Status AUS

d.h. unsere  Lampe im Hausflur (die hängt am Powerport der auf Gruppe 70 hört) ist eingeschaltet worden.

Die Paare 9-12 aus dem Paket enthalten die oben beschriebenen Daten.

Woran erkennst du am Telegramm das es deine Lampe im Hausflur ist und nicht die Lampe im Wohnzimmer?

Jedem Raum ist bei mir eine Gruppe zugeordnet. Gruppe 70(-79) ist unser Hausflur
Ich habe Gruppen im EG von 10(Küche)-80(GästeWC) und im
                                  OG von 110(Bad) bis 160(Ankleide).

Die Gruppennummern dürfen sich überschneiden, da das System nicht nur die Gruppe, sondern auch das "Kommando" mit Berücksichtigit.
Also Powerport Gruppe 60 würde keinen Raffstore der eine Gruppe 60 eingetragen hat ansteuern.

Gruppe 60(-69): Büro ist vielleicht ein besseres Beispiel als der Flur.
Hier ist:
- Powerport mit Gruppe 60 Hauptbeleuchtung
- Powerport mit Gruppe 61 Stehlampe am Schreibtisch
- Rolladen mit Gruppe 61 1. Raffstore gezählt von Norden im Uhrzeigersinn
- Rolladen mit Gruppe 62 2. "

Außerdem habe ich noch gobale Gruppen (wo es sinnvoll ist). Diese beinhalten z.B. das Geschoss (UG/EG/OG 90,91,92) die Himmelsrichtungen (NSOW/96,97,98,99)

Der linke Raffstore im Büro, das befindet sich im EG als Eckraum Nord Ost Ausrichtung. Hat also z.B. folgende 4 Gruppen eingetragen:
Gruppe 0 = 61 Darauf reagiert nur er selbst.
Gruppe 1 = 60 Hauptgruppe Büro (Mit Rolladen_Position_Set=100 an Gruppe 60 fahren alle Raffstores im Büro hoch)
Gruppe 2 = 91 Geschoss EG (Mit Rolladen_Position_Set=100 an Gruppe 91 fahren alle Raffstores im gesamten EG hoch)
Gruppe 3 = 96 Himmelsrichtung (Mit Rolladen_Position_Set=100 an Gruppe 96 fahren alle Raffstores in Himmelsrichtung Nord hoch)

Waran erkennst du das es eine Lampe und kein Sensor ist?

Am 2. HEX Wert.
Im obigen Beispiel war es eine
11: Power_Group_State_Info
Wenn ein Sensor senden würde, wäre es z.B: eine
47: HELLIGKEITS_INFO oder eine
22: 1WIRE_TEMPERATURE

Ist ein wenig komplex. Hoffe es ist gut genug erklärt...

[CoolTux]

Lese ich mir morgen in Ruhe durch und dann schauen wir mal wie wir weiter machen.


Grüße

[CoolTux]

Das gibt ganz schön Kopf auha, aber schauen wir mal was wir zusammen hin bekommen.
Fangen wir erstmal mit dem Master Modul an und arbeiten uns dann langsam vor.

10_openHCAN_hcand.pm
20_openHCAN.pm

Was sagst Du zu der Namensbenennung? Kannst Dich damit anfreunden?


Beim Mastermodul werden wir wohl nicht viel brauchen. Anlegen, aufbau der Socketverbindung, schließen der Socketverbindung. Wenn Du denkst man kann im Master noch sinnvolle Readings setzen dann sag Bescheid.





Grüße

[GU!DO]

Wir können das open auch weg lassen. Ursprünglich hieß es nur HCAN. Ist weniger "Schreibarbeit".

Sinnvolle Readings für den Master fallen mir grad nicht ein. Die können wir ja auch noch nachlegen.

Da ich nicht wußte, was ich als nächstes am besten mache, habe eben schon mal den HEX String zerlegt, und versuche mich grad daran, mittels der gewonnenen Zahlen die zugehörigen Befehle aus einer hcan xml Datei zu lesen.

[GU!DO]

So, was lange währt wird endlich gut...

Ich bin mittlerweile überzeugt:
Perl ist die Summe aller Gemeinheiten, die der liebe Gott bei den Frauen nicht unterbringen konnte. 

Ich habe das Modul erweitert. Es liest aus der angehangenen xml Datei die HCAN "Befehle" vom Bus und gibt sie im Logfile mit aus.
Ich hoffe, die Zuordung wird damit etwas klarer.

Die Logausgabe sieht nun wie folgt aus:

Code Auswählen Erweitern


2017.11.02 19:35:44 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.02 19:35:44 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 688d1000040000000501460004930408
2017.11.02 19:35:44 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten:TASTER_DOWN Gruppe:70 Status:0
!!!Set
!!!Set
!!!Set
!!!Read
2017.11.02 19:35:44 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.02 19:35:44 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 68911003040000000511460104930408
2017.11.02 19:35:44 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten:POWER_GROUP_STATE_INFO Gruppe:70 Status:1
!!!Set
!!!Set
!!!Set
!!!Read
2017.11.02 19:35:45 4: HCAN_Test (HCAN_Test) - ReadFn gestartet
2017.11.02 19:35:45 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten: 688d1000040000000502460004930408
2017.11.02 19:35:45 3: HCAN_Test (HCAN_Test) - Daten Empfangen. Länge: 16 - Daten:TASTER_UP Gruppe:70 Status:0



[GU!DO]

Das war wohl nix mit der angehängten xml Datei.
Vermutlich war das FHEM Forum nicht sonderlich Begeistert über meine Gedanken zu perl... 
Aber jetzt: