Anbindung an openHCAN

[CoolTux]

Die Ausgaben sehen schon Mal gut aus.

Dann schlage ich vor wir machen die Namensnennung beim automatischen anlegen erstmal mit Gruppe.
Wobei ich da immer noch nicht ganz durch blicke. Ist das nun ein einziges Gerät.
POWER_GROUP_STATE_INFO
Ist ein Lichtschalter hast du gesagt.
TASTER_UP
Ist das der selbe Lichtschalter und sagt mir das das es ein Dimmer ist?

[GU!DO]

Die Technik ist schon ziemlich komplex. Da ist es bestimmt sehr schwer sich so nebenbei herein zu Denken.

TASTER_DOWN Gruppe:70
wird gesendet, wenn ein Taster bei dem Gruppe 70 eingetragen ist gedrückt wird.

Teilt also den HCAN Powerport-Devices bei denen eine der 4 Gruppen auf 70 konfiguriert ist mit, dass sie Schalten sollen.

POWER_GROUP_STATE_INFO Gruppe:70
wird von den HCAN Powerport-Devices, die die Gruppe 70 eingetragen haben gesendet, sobald der im Device verkjnüpfte Ausgang des Prozessors ein geschaltet ist.
Dh. es ist die Rückmeldung, dass der Prozessor den Schaltbefehl ausgeführt hat. Daher auch das INFO im Namen.

TASTER_UP Gruppe:70
wird erst dann gesendt, wenn der Taster wieder losgelassen wird. Führt aber hier zu keiner Reaktion.
Das könnte z.B. bei einem Dimmer sinnvoll sein, damit der elektronische Regler weiß, dass der Taster losgelassen wurde, und der Dimmvorgang beendet werden muß.

Ich hoffe, es wird so langsam klarer...

[CoolTux]

Sag mal jetzt wo ich da so drüber nach gedacht habe. Im Grunde ist doch nichts fix. Deine Gruppe 70 zum Beispiel. Du hast ja irgendwo irgendwie Mal festgelegt das ist jetzt ein Lichtschalter Wohnzimmer. Im Grunde kann man auch sagen das ist jetzt ein Temperatursensor Badezimmer, oder?

Ich kann also auf Basis Deines Telegrammes nicht prinzipiell festlegen das ist ein Sensor und das ein Aktor. Und bei Aktor du bist Dimmer du bist Taster, da sich jeder selber aufbauen kann was welches Telegramm bedeutet. Also Gruppe und so.



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


Was ist an dem Telegramm von oben fix? Was siehst immer gleich aus?




Daten: 688d1000040000000501460004930408
Daten:TASTER_DOWN Gruppe:70 Status:0


Daten: 68911003040000000511460104930408
Daten:POWER_GROUP_STATE_INFO Gruppe:70 Status:1


Daten: 688d1000040000000502460004930408
Daten:TASTER_UP Gruppe:70 Status:0

Ist das ein und der selbe Schalter aus deinem Beispiel von oben?
Wieso ist bei den drei Beispielen bei zwei eine 688d am Anfang und bei einem eine 8991

Kann man davon ausgehen das immer eine 68 als erstes kommt? Also bei allen auf der Welt oder ist das nur bei Dir. Frage nur wegen RegEx 

[CoolTux]

Kannst du mir noch verraten was Dir aus diesem Telegramm
688d1000040000000501460004930408
Eindeutig sagt das es der Lichtschalter Deckenlampe Kinderzimmer(Beispiel) ist?

05 und 46
Sind ja beides Gruppen

05 = ist die Gruppe, die erstmal am intessantesten ist, diese enthält alle Pakete zur Device Kommunikation.
Habe gerade Mal drüber nachgedacht. Sicherlich beschreibt die 05 alleine nicht das alles.
Meintest du damit das 05 die Beschreibung einleitet? Also alles was nach 05 kommt zum Beispiel
05 01460004930408
In dem Fall würde 05 bedeuten das alles danach die Daten für die devicekommunikation enthält
Also 01460004930408 ist dann die devicekommunikation

01 01460004930408
Hier wäre alles nach 01 Daten für Erreichbarkeit und uptime des Controlerboards. Welches das ist steht dann sicher auch im Folgecode, oder?

Also beschreibt die Stelle 9 zu was die Folgedaten gehören.

Gruppe 70 also die 46 steht nun für den Schalter(Beispiel Flur)? Kann ich also die 70 nehmen und in FHEM eintragen und wenn ich da ein on sende geht auch wirklich der Schalter Flur an?



Grüße

[CoolTux]

Gedankenblitz Gedankenblitz

Eigentlich geht es ja gar nicht um direkte Devices, also nicht in erster Linie.
Es geht ja um Controlerboards. Eigentlich ist ein Device erstmal ein Controlerboard. Die die Ein und Ausgänge stehen für ein entsprechendes zu schaltenes Device. Es können also auch 2 oder 3 Lampen an ein Board dran sein. Frage ist nun. Woran unterscheiden sich die Boards im Bezug auf das Datagramm? Gibt ja bestimmt eine einmalige BoardId oder so.
Und wie kann ich nun Anhand der Daten vom Board sehen wie viele Devices tatsächlich damit geschalten werden. Das könnte man dann als Channels abbilden. Also das Board ist das Hauptgerät und dann werden noch Channel Devices angelegt. Die Channeldevices bekommen als attribut subType wo dann ausgewählt werden kann THSensor oder Switch oder Dimmer oder Rolladenblabla




Grüße

[GU!DO]

Guten Morgen!
Ich bin zwar auch schon seit 2 Std. wach, war aber nicht so produktiv wie Du. Hut ab!
Ich hoffe, ich bin nicht der Grund für Deine Bettflucht?!?

Also Du bist nah dran, aber auch weit weg...

Ich glaube Dir geht es grad ähnlich, wie mir mit dem OSI Modell, da hab ich auch Zeit und verschiedenen Erklärungen gebraucht, bis ich das verstanden hatte.

Verabschiede Dich einfach von den Boards. Das ist ein Layer den wir hier nicht benötigen.
Die haben eine Adresse. Diese Adresse ist auch in den Paketen enthalten die wir Empfangen. Die ist aber völlig unrelevant und dient ausschließlich der Wartung der Boards. Also: Firmware updates, Ändern der Konfiguraton.
D.H. Du verbindest dich über die Boardadresse auf das Controllerboard. Sagst: Create Device Taster um einen Taster zu erstellen. Der Taster bekommt vom Controllersystem eine ID zugeweisen sagen wir mal die 23. Dann sagst Du: Edit 23. und kannst Dir mit List die Konfiguration anzeigen lassen.
Wenn Dein phyischer Taster an Port5 des Controllers angeschlossen ist, legst Du das mit "set Port 5 in der Konfiguration des Tasters fest.
Danach kannst Du mit set Gruppe 70 sagen, dass der Taster unter der Gruppe 70 senden soll. Damit ist das angelegte Tasterdevice konfiguriert.
Du kannst auf diesem Controller aber noch x andere Devices anlegen. Z.B. Powerport, Rolläden usw. bis alle der 8 Ein und 20 Ausgänge vergeben sind.

Auf den Boards werden, wie gesagt, Devices angelegt. Im Prinzip wie bei FHEM. Dieses Devices können Taster, Powerports, Rolladen, Temperatursensoren oder auch eine Zeitschaltuhr sein. https://github.com/hcanIngo/openHCAN/wiki/device

Die Daten auf dem Bus:

Alles was an für uns relevanten Nutzdaten (Stelle 9-12 im hex) auf dem Bus gesendet wird, findet sich in der oben angehängten XML Datei.
Die Kommunikation ist in Gruppen aufgeteilt. Die Nachrichten-Gruppe 05 ist erstmal am interessantesten, da dort die Schaltbefehle und Info Nachrichten der Devices enthalten sind.

Die Nachrichten-Gruppe Steht an 9. Stelle im hex code.

Anhand des hex Codes läßt sich nicht direkt ermitteln, ob die Mitteilung von einem Aktor oder von einem Sensor kommt.

Das Wichtigste ist:
Die Kommunikations-Gruppen (Stelle 11 im Hex) werden immer im Zusammenhang mit der Nachricht (Stelle 10 im hex) interprätiert.

Nehmen wir mal den o.g. Taster. Dessen Device (im HCAN Controller) auf Kommunikations-Gruppe 70 programmiert ist.
In der Standardeinstellung sendet er beim Drücken: TASTER_DOWN 70. Beim loslassen TASTER_UP 70.

Ein Powerport z.B: ist so programmiert (also intern im C Quellcode), dass er auf alle Events des Typs TASTER_DOWN reagiert.
Wenn der User ihm dann auch noch die Gruppe 70 eingetragen hat weiß er, dass er reagieren muß wenn TASTER_DOWN 70 gesendet wird.

Ich hoffe, es ist etas mehr Licht ins Dunkel gekommen?!?

[CoolTux]

Verdammt.
Also

Der Taster bekommt vom Controllersystem eine ID zugeweisen sagen wir mal die 23. Da

Wo bekomme ich diese ID her aus dem Telegramm??? Das ist das was ich brauche um das Gerät eindeutig zu identifizieren. So das ich in FHEM ein Device angelegt bekomme was im DEF 23 zu stehen hat und wo ich dann sagen kann subType Switch so das mir als set nur on oder off angezeigt wird (und bisschen on-for-timer oder so).
Verstehst was ich meine?



Grüße

[GU!DO]

Es tut mir leid, aber so funktioniert das System nicht.
Die 23 ist eine Interne Devicenummer auf dem Controller. Damit das Device im EDS (ist so eine Art Dateisystem für EProms) angesprochen werden kann.

Du kannst ein Device an keiner Nummer identifizieren.

Der Devicetyp läßt sich durch die Nachrichten die er Versendet/ Empfängt identifizieren.

Ein Taster sendet TASTER_DOWN mit Gruppe 70 und
ALLE Powerports die Gruppe 70 eingetragen haben reagieren darauf. Es kann einer sein, oder auch hunderte.

Außerdem hat ein Tasterdevice noch ein Featurebit, das bei der Konfiguration eingetragwn wird.
Steht dieses auf 0, sendet er TASTER_DOWN => es reagieren Powerports /sofern die Gruppe stimmt
Steht es auf 2 sendet er ROLLADEN_UP => es reagieren Raffstores /sofern die Gruppe stimmt
Steht es auf 4 sendet er ROLLADEN_DOWN  => es reagieren Raffstores /sofern die Gruppe stimmt

Die Featurebits waren aus dem Kopf genannt. Kann sein, dass die Nummern verdreht sind. Bin grad unterwegs und schreibe vom Handy.

Wir müssen als eine Nachricht im Zusammenhang mit einer Gruppe versenden/analysieren.
Also die Stellen 10+11 des Telegramms.

[CoolTux]

Aber dann können auch mehrere Taster die 70 haben. richtig?
Wenn ja muß ich mir was einfallen lassen. Wir brauchen eine eindeutige ID für jedes logische Device was in FHEM angelegt wird.

[GU!DO]

Ja das stimmt.

Die Lampe in einem Flur z.B. reagiert auf TASTER_DOWN Gruppe 70.
Dann hast Du einen Schalter am Anfang und einen am Ende des Flurs, und beide senden TASTER_DOWN 70 auf den Bus.

Muß denn die ID gleich dem "Telegramm" sein, das ein Device sendet, bzw. auf das ein Device Reagiert?

Könnten wir denn dafür die Summe aus Befehl und Gruppe nehmen.

Wenn z.B. die Lampe(n) im Flur abgebildet werden sollen, ist die Device ID "TASTER_DOWN 70". Oder die gesendeten Hex Werte: 01 46

[CoolTux]

Es muß eine Herleitung aus dem Telegramm möglich sein. Also ja.

Könnten wir denn dafür die Summe aus Befehl und Gruppe nehmen.

Da könnte man machen.

Ja das stimmt.

Die Lampe in einem Flur z.B. reagiert auf TASTER_DOWN Gruppe 70.
Dann hast Du einen Schalter am Anfang und einen am Ende des Flurs, und beide senden TASTER_DOWN 70 auf den Bus.

Dann brauche ich also quasi für FHEM ja nur ein Abbild eines Tasters der Gruppe 70 sendet. Korrekt?
Gleichzeitig muß dieses FHEM Device aber auf genau diese Lampe welche auf Gruppe 70 reagiert auf die Telegramme für Gruppe 70 reagieren. Damit wir ein ACK bekommen. Also eine Bestättigung das die Lampe auch tatsächlich geschalten hat.

[GU!DO]

Dann brauche ich also quasi für FHEM ja nur ein Abbild eines Tasters der Gruppe 70 sendet. Korrekt?

yep!

Ich möchte Dich nicht verwirren - aber der Vollständigkeit halber:
Neben dem TASTER_DOWN Events reagieren die Powerports auch auf POWER_GROUP_ON und POWER_GROUP_OFF.
Das ist wahrscheinlich der eindeutigere Befehl.

Ein Taster sollte also je nach Funktion z.B. senden können:

Code Auswählen Erweitern

POWER_GROUP_OFF Gruppe 70 oder in hex: 0a 46  und
POWER_GROUP_OFF Gruppe 70 oder in hex: 0b 46

bzw. um einen Rolladen zu steuern zusätzlich zum Befehl und der Gruppe noch die Positon:

Code Auswählen Erweitern

HES ROLLADEN_POSITION_SET Gruppe 70 Position 100  oder in hex: 14 46 64

Gleichzeitig muß dieses FHEM Device aber auf genau diese Lampe welche auf Gruppe 70 reagiert auf die Telegramme für Gruppe 70 reagieren. Damit wir ein ACK bekommen. Also eine Bestättigung das die Lampe auch tatsächlich geschalten hat.

Richtig!
Dieses FHEM Device muß auf Nachrichten die an Gruppe 70 gesendet werden reagieren. Aber immer mit einem Filter auf die Nachricht selber. Es darf, als Lampe, natürlich nicht auf ein "ROLLADEN_POSITION_SET Gruppe 70" reagieren.

Noch was:

Es gibt eine Datei im hcan System, die optional ist, aber für unsere Zwecke ideal verwendt werden kann. Diese spiegelt die jeweilige Installation als xml Datei wieder:

Code Auswählen Erweitern

`<haus>`
      `<board addr="400">`
      `</board>`
      `<board addr="401">`
              `<reedkontakt gruppe="1" name="hobbyraum" />`
              `<reedkontakt gruppe="2" name="werkstatt" />`
              `<tempsensor gruppe="4" name="werkstatt" />`
              `<tempsensor gruppe="3" name="waschkueche" />`
              `<tempsensor gruppe="5" name="vorratsraum" />`
              `<powerport typ="lampe" gruppe="10" name="Vorratsraum" />`
              `<powerport typ="lampe" gruppe="20" name="Kueche" />`
              `<powerport typ="lampe" gruppe="70" name="Flur" />`
              `<tempsensor gruppe="1" name="hobbyraum" />`
              `<heizung gruppe="1" name="hobbyraum" />`
              `<heizung gruppe="2" name="werkstatt" />`
      `</board>`
`</haus>

Ich wollte eigentlich  für jedes HCANDevice ein FHEM Device erstellen und diese Datei als Grundlage nehmen, um dem User nur die jeweils gültigen Attribute anzuzeigen.

Ein user hätte z.B. ein Device mit:  "define LampeImHausflur HCAN_Lampe" angelegt.

Er hätte dann in den Attributen zwischen: Lampe Vorratsraum, Kueche und Flur wählen können und hätte die anderen Devices nicht angezeigt bekommen.
Hätte er ein Raffstore_Device angelegt, hätte er nur eingetragene Raffstores zur Auswahl bekommen, hätte aber zusätzlich noch den Öffnungs-Parameter angeben müssen.

Ich habe keine Ahnung wie wir das am besten in einem einzigen logischen FHEM Device abbilden.
Der Öffnungs Parameter ist für ein Raffstore zwingend. Die Lampe kann damit aber nix anfangen.


Ich hatte im Vorfeld schon mal ein Modul zum Senden gebaut. Soll ich das in unser 2 Modul Konzept einbauen und Du korrigierst es, oder was schlägst Du vor. Nicht das wir parallel am gleichen Arbeiten...

[GU!DO]

Sorry, oben ist ein Vertipper:

Code Auswählen Erweitern

POWER_GROUP_OFF Gruppe 70 oder in hex: 0a 46  und
POWER_GROUP_OFF Gruppe 70 oder in hex: 0b 46

es muß natürlich heißen

Code Auswählen Erweitern

POWER_GROUP_ON Gruppe 70 oder in hex: 0a 45  und
POWER_GROUP_OFF Gruppe 70 oder in hex: 0b 46

[CoolTux]

Häng das einfach mal hier mit an. Am We sollte ich dazu kommen da mal was an zu fangen.

[CoolTux]

Kannst natürlich gerne auch versuchen die Dinge die Du weißt schon in das 2 Modulkonzept ein zu bauen.