Homebrew Devices, XML und anlegen von peerings

[loetmeister]

Hallo,

ich habe mir ein neues Homematic Wired Device erstellt (Arduino) und dazu passend eine XML.
Es gibt insgesamt 18 Kanäle (siehe Anhang), je nach Typ eine eigene EEPROM Startadresse (address_start) für die peerings... Habe sie der Übersich halber mal dazu geschrieben,
Wenn ich in FEHM ein (lokales) peering erstelle wird eine falsche Startadresse verwendet... ich verstehe leider nicht warum 

Ich peere Kanal 02 mit 13, da erwarte ich Startadresse 0x100 und 0x178. FEHM aber nimmt:

Code Auswählen Erweitern

HBW_CC_DT3_T6_HBW7296304: convertPeeringsToEepromData peerId: 0 start: 0x1A2 step: 6 offset: 424
HBW_CC_DT3_T6_HBW7296304: convertPeeringsToEepromData peerId: 0 start: 0x178 step: 7 offset: 383
HBW_CC_DT3_T6_HBW7296304: HM485_UpdateConfigReadings called

0x1A2 ist für "key" und "delta_t" gesetzt, nicht aber bei den Kanälen welche ich 'gepeered' hab...

XML: https://github.com/loetmeister/HBWired/blob/master/HBW-CC-DT3-T6/HBW_CC_DT3_T6.xml

Jemand eine Idee?   

Gruß,
Thomas

[Thorsten Pferdekaemper]

Hi,
ich habe jetzt nicht ins Coding geschaut, aber ich würde mal annehmen, dass die FHEM-Routinen ein bisschen verwirrt sind, wenn dasselbe address_start mehrfach vorkommt. Wozu soll das überhaupt gut sein?
Gruß,
   Thorsten

[loetmeister]

Hi Thorsten,

der Grund, warum ich die XML so "komisch" erstellt habe, ist die Kanäle logisch zu trennen, d.h. ihnen einen eigenen Typ/Namen zu geben und es so Übersichtlicher in FEHM zu machen.
Die Kanäle 10 bis 15 nutzen das selbe peering Objekt, daher nur eine Startadresse (LINKADDRESSSTART_DELTATX). Intern sind sie aber unterschiedlich verknüpft, delta_t1 und delta_t2.

Code Auswählen Erweitern

Line 164: <paramset type="LINK" id="hmw_input_t_ch_link" peer_param="ACTUATOR" channel_param="CHANNEL" count="20" address_start="0x100" address_step="6">
Line 266: <paramset type="LINK" id="hmw_deltat_ch_link" peer_param="ACTUATOR" channel_param="CHANNEL" count="12" address_start="0x1A2" address_step="6">
Line 385: <paramset type="LINK" id="hmw_teltatx_ch_link" peer_param="SENSOR" channel_param="CHANNEL" count="6" address_start="0x178" address_step="7">
Line 449: <paramset type="LINK" id="hmw_teltatx_ch_link" peer_param="SENSOR" channel_param="CHANNEL" count="6" address_start="0x178" address_step="7">
Line 550: <paramset type="LINK" id="hmw_input_ch_link" channel_param="CHANNEL" peer_param="ACTUATOR" count="12" address_start="0x1A2" address_step="6">

Ich hatte erwartet das sich FEHM die Startadresse des jeweiligen Kanals nimmt...

Wenn ich nun die Möglichkeit des peerings für Kanal 7 bis 9 und 13 bis 18 entferne "hmw_deltat_ch_link" und "hmw_input_ch_link" (Den kompletten Block "<paramset type="LINK"..." welche beide address_start="0x1A2" nutzen), dann kann ich zunächst kein Peering mehr anlegen:
set peer HBW_CC_DT3_T6_HBW7296304_02 no free PeerId found
(Wieder Kanal 02 mit 13)
Es funktioniert erst, sogar mit Startadresse 0x100 wenn ich die <link_roles><source name="SWITCH"/> für Kanal 7 bis 9 (Typ DELTA_T) lösche... (link_roles scheint die option für peering zu aktivieren, egal ob es paramset type="LINK" gibt...?)

Was hat aber Kanal 7 bis 9 mit der Anlage eines Peerings für Kanal 02 mit 13 zu tun?

Es folgt ganz sicher einer Logik... leider ist sie mir bisher verschlossen 

Gruß,
Thomas

[Thorsten Pferdekaemper]

Hi,
ich habe gerade nochmal das Coding scharf angeschaut. Ich glaube, es ist noch blöder, als ich gedacht hatte. Soweit ich das sehe, kann es momentan nur eine liste von Peerings jeweils für actuator und sensor geben. (Das ist halt intern der Key...)
D.h. Du müsstest den allen actuator-Peerings dieselbe Startadresse geben und allen sensor-Peerings. (Allerdings bin ich mir nicht 100% sicher, ich habe das auch nicht selbst geschrieben.)
...und ja, link_roles aktiviert das Peering im Prinzip, aber es wird dann erwartet, dass es auch einen link-Eintrag gibt.
Gruß,
   Thorsten

[loetmeister]

Hi Thorsten,

danke. Klingt soweit logisch und erklärt das Verhalten das einfach das zuletzt in der XML konfigurierte peering, also diese Adresse genommen wird.

Wenn es nur jeweils eine Startadresse für alle actuator-Peerings und alle sensor-Peerings in einem Device geben kann, dann müssten auch actuator-und sensor-Peerings das selbe EEPROM Layout haben (EEPROM_SIZE / "address_step" in XML).

In Summe ist dann leider meine letzte HBWired Erweiterung ein wenig für die Katz... 
Eine eigene Klasse von HBWLinkReceiver bzw. HBWLinkSender abgeleitet, ist, zumindest für numLinks und eepromStart nicht nötig. Mal sehen ob ich das wieder etwas vereinfachen kann.
Die Funktionen linkReceiverInfo->receiveInfoEvent(...) und linkSenderInfo->sendInfoEvent(...) könnten Teil einer Klasse mit receive/sendKeyEvent sein...

Für das Aktuelle Device "HBW-CC-DT3-T6" sollte es mit einer Startadresse funktionieren.
EDIT, es funktioniert tatsächlich..
XML

Code Auswählen Erweitern


Line 164: <paramset type="LINK" id="hmw_input_t_ch_link" peer_param="ACTUATOR" channel_param="CHANNEL" count="32" address_start="0x100" address_step="6">
Line 265: <paramset type="LINK" id="hmw_deltat_ch_link" peer_param="ACTUATOR" channel_param="CHANNEL" count="32" address_start="0x100" address_step="6">
Line 382: <paramset type="LINK" id="hmw_teltatx_ch_link" peer_param="SENSOR" channel_param="CHANNEL" count="6" address_start="0x220" address_step="7">
Line 444: <paramset type="LINK" id="hmw_teltatx_ch_link" peer_param="SENSOR" channel_param="CHANNEL" count="6" address_start="0x220" address_step="7">
Line 545: <paramset type="LINK" id="hmw_input_ch_link" peer_param="ACTUATOR" channel_param="CHANNEL" count="32" address_start="0x100" address_step="6">


Code Auswählen Erweitern


HBW_CC_DT3_T6_HBW7296304: convertPeeringsToEepromData peerId: 0 start: 0x100 step: 6 offset: 262
HBW_CC_DT3_T6_HBW7296304: convertPeeringsToEepromData peerId: 0 start: 0x220 step: 7 offset: 551


Gruß,
Thomas

[Thorsten Pferdekaemper]

Hi,
sorry, dass ich momentan so lange für eine Antwort brauche...
Gut, dass es jetzt funktioniert. Falls Du dazu einen Änderungsvorschlag hast, dann baue ich das ggf. ein. Ich habe gerade ein Update meines "Produktivsystems" gemacht und könnte daher auch ganz neue Sachen ausprobieren.
Allerdings bin ich mir nicht so sicher, ob das mit den Peerings mit derselben Adresse wirklich so toll ist. Es macht das ganze ja eher komplizierter.
Gruß,
   Thorsten

[loetmeister]

Hallo Thorsten,

kein Problem.

Es funktioniert ja, mit der Einschränkung, das ich alle aktor und alle sensor peerings jeweils mit dem selben "address_step" arbeiten müssen.
Schöner wäre es wenn FHEM für die LINKs die in der XML definierten "address_start" und "address_step" nehmen würde... Aber wenn das Problem nur für meine Selbstgebauten Geräte gilt ist das eigentlich nicht so tragisch...

Andere Probleme, wie das folgende sind schon etwas unschöner.... 
https://github.com/kc-GitHub/FHEM-HM485/issues/64

Gruß,
Thomas

[loetmeister]

Hi,

Etwas andere Baustelle, aber gleiche Thema. Bastel mir grad den 6-Fach Taster passend, d.h. I2C sensor und Peering für die Temperatursensoren.
So wie Viktor die ursprüngliche HBWired Software an dieser Stelle umgebaut hat, kann ich beliebig viele verschiedene Peerings erstellen. Die start Adresse ergibt sich aus der konfig Struktur, die das gesamte EEPROM abbildet. Damit wäre es einfacher die Adressen individuell in der xml zu definieren. Hier habe ich mir mit einem "dummy peering" geholfen, welcher in der xml übergangen wird, im Code aber von der zusätzlichen Peering Klasse und der direkt folgenden genutzt wir. 

https://github.com/loetmeister/HBW-Devices/commit/0972a73512137738bf5eec2e0bef59b22182424f

Gruß,
Thomas

[Thorsten Pferdekaemper]

Hi,
ich verstehe nicht wirklich, was Du damit meinst bzw. von mir erwartest. "Beliebig viele Peerings" halte ich für unwahrscheinlich, da ja irgendwann mal der Speicher voll ist. ...und die Konfig-Struktur sollte auf einem "kleinen" Arduino besser nicht das ganze EEPROM abbilden, sonst gibt's schnell Speicherplatzprobleme im RAM. Oder ich verstehe nicht, was gemeint ist.
Gruß,
    Thorsten

[loetmeister]

Hi Thorsten,

sorry, was etwas zusammenhanglos und knapp geschrieben. 
Es war eigentlich nur ein Bespiel, bei dem ich eine Lösung für die Einschränkung der Peerings finden konnte, nachdem ich, mit deiner Hilfe verstanden habe wo das Problem liegt, bzw. wie FHEM die XML verarbeitet.

Auch überlege ich noch wie ich meine neuen Klassen linkReceiverInfo und linkSenderInfo etwas einfacher/flexibler einbauen kann. Über "#if defined(Support_HBWLink_InfoEvent)" ist es leider nicht so übersichtlich. Schöner wären separate header Dateien.

"Beliebig viele Peerings" stimmt natürlich nicht, ich meinte eher das ich viele verschiedene peering typen parallel einbinden könnte, z.B. HBWLinkKey, HBWLinkInfoEventSensor, etc. Dazu ein Pointer auf die EEPROM Struktur des peerings (statt ADRESS_start + ADDRES_STEP)

Code Auswählen Erweitern

class HmwLinkInfoEvent : public HmwLinkSenderInfoEvent
{
   public:

      struct Config
      {
         uint8_t ownChannel;
         uint32_t actorAddress;
         uint8_t actorChannel;
      };

      HmwLinkInfoEvent( uint8_t _numLinks, Config* _links );
      IStream::Status sendInfoEvent( uint8_t srcChan, uint8_t const* const data, uint8_t length );


   private:
      uint8_t numLinks;         // number of links of this type
      Config* links;            // size sollte konstant sein -> als define in .cpp
};

Gruß,
Thomas

[Thorsten Pferdekaemper]

Auch überlege ich noch wie ich meine neuen Klassen linkReceiverInfo und linkSenderInfo etwas einfacher/flexibler einbauen kann. Über "#if defined(Support_HBWLink_InfoEvent)" ist es leider nicht so übersichtlich. Schöner wären separate header Dateien.

Was hält Dich davon ab, separate Header-Dateien zu verwenden? Das wird dann doch sowieso ins Hauptprogramm eingebunden, und das ist immer unter der Kontrolle dessen, der das Gerät (bzw. die Geräte-Firmware) entwickelt.

"Beliebig viele Peerings" stimmt natürlich nicht, ich meinte eher das ich viele verschiedene peering typen parallel einbinden könnte, z.B. HBWLinkKey, HBWLinkInfoEventSensor, etc. Dazu ein Pointer auf die EEPROM Struktur des peerings (statt ADRESS_start + ADDRES_STEP)

Das verstehe ich jetzt wieder nicht. ADDRESS_START und ADDRESS_STEP ist doch im XML, damit FHEM (oder auch die CCU) die Adresse eines bestimmten Peerings im EEPROM findet. Die Firmware darf das auch anders machen, ich frage mich allerdings, wo diese Pointer dann gespeichert sein sollten. Man bräuchte dann ja eine weitere Liste, ggf. mit Markierung, welcher Speicherbereich tatsächlich ein gültiges Peering enthält.
...und für Peerings mit unterschiedlicher Größe in derselben Liste müsste man ein neues Speichermanagement schreiben, da man dann beim Löschen von Peerings unterschiedlich große "Löcher" produziert. Außerdem müsste man für Peerings mit unterschiedlichen Feldern einiges in FHEM ändern. (Und wahrscheinlich funktioniert sowas in einer CCU sowieso nicht.)

Aber vielleicht ist das alles auch nur mal wieder ein Missverständnis.
Übrigens hoffe ich, dass ich mich ab September wieder ein bisschen mehr mit HMW befassen kann. Vorher wird das nichts.

Gruß,
   Thorsten

[loetmeister]

Hi Thorsten,

Was mir zu dem eigentlich Problem noch aufgefallen ist... (eigentlich keine Überraschung...)

Es funktioniert ja, mit der Einschränkung, das ich alle aktor und alle sensor peerings jeweils mit dem selben "address_step" arbeiten müssen.

Es wird für das peering nicht nur das selbe "address_start" und "address_step" genommen, auch die weiteren Parameter aus paramset type="LINK" sind die selben, SHORT_ACTION_TYPE, LONG_ACTION_TYPE, usw.
War zu erwarten, hatte da aber nicht dran gedacht...
D.h. ich würde meine ursprüngliche Aussage etwas relativieren... es funktioniert doch nicht so gut  Besser wäre den gesamten paramset type="LINK" individuell für die Kanäle nutzen zu können. ("address_start", "address_step", "parameter id=..", usw)

Was hält Dich davon ab, separate Header-Dateien zu verwenden? Das wird dann doch sowieso ins Hauptprogramm eingebunden, und das ist immer unter der Kontrolle dessen, der das Gerät (bzw. die Geräte-Firmware) entwickelt.

Ich bin mir nicht sicher ob ich das mit der Arduino IDE hin bekomme. Die lib liegt ja Zentral im Arduino lib Verzeichnis, meine Header Dateien, für linkReceiver und linkSender wären aber Geräte spezifisch. Im Sketch kann ich beliebige header Dateien einbinden, im HBWDevice habe ich aber noch Abhängigkeiten (HBWDevice::receiveKeyEvent, HBWDevice::receiveInfoEvent, o.ä)... das zu separieren erscheint mir grade nicht so einfach.

Das verstehe ich jetzt wieder nicht. ADDRESS_START und ADDRESS_STEP ist doch im XML, damit FHEM (oder auch die CCU) die Adresse eines bestimmten Peerings im EEPROM findet. Die Firmware darf das auch anders machen, ich frage mich allerdings, wo diese Pointer dann gespeichert sein sollten.

Ja, es ging nur um die Startadresse in der Firmware, als pointer zum struct (Config* links) - der Rest bleibt gleich, es müssen alle möglichen peerings geprüft werden ob sie leer sind oder gültige Werte enthalten. Ich wollte da gar nicht so stark drauf eingehen, ich hatte es nur erwähnt, das man nicht mehr die Startadressen ausrechnen muss. (auch nur halb wahr, ich muss sie natürlich kennen und in die XML eintragen  )

Übrigens hoffe ich, dass ich mich ab September wieder ein bisschen mehr mit HMW befassen kann. Vorher wird das nichts.

Ich drück die Daumen dafür. 

Gruß,
Thomas

[Thorsten Pferdekaemper]

Was mir zu dem eigentlich Problem noch aufgefallen ist... (eigentlich keine Überraschung...)

Ja, genau. Deshalb hatte ich ja geschrieben:

Außerdem müsste man für Peerings mit unterschiedlichen Feldern einiges in FHEM ändern. (Und wahrscheinlich funktioniert sowas in einer CCU sowieso nicht.)

Vielleicht ist das im Rest untergegangen.
Gruß,
   Thorsten

[loetmeister]

Hi,

sorry, die "unterschiedlichen Feldern" hatte ich nicht auf die Peering Parameter bezogen. Aber du hast recht, ich sollte erst mal mit einer CCU testen, bevor FHEM verbastelt wird. 

Gruß,
Thomas

[Thorsten Pferdekaemper]

Hi,
hast Du dazu mal irgendwas probiert mit der CCU?
Ich habe mir jetzt nochmal für FHEM dazu Gedanken gemacht, aber das ganze würde ziemlich aufwändig werden.
Brauchst Du das noch?
Gruß,
   Thorsten