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:
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? ;D
Gruß,
Thomas
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
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.
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 ;D
Gruß,
Thomas
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
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
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">
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
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
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.... ;D
https://github.com/kc-GitHub/FHEM-HM485/issues/64
Gruß,
Thomas
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
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
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)
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
Zitat von: loetmeister am 01 August 2019, 20:56:24
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.
Zitat
"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
Hi Thorsten,
Was mir zu dem eigentlich Problem noch aufgefallen ist... (eigentlich keine Überraschung...)
Zitat von: loetmeister am 28 Juli 2019, 20:30:46
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 ;D 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)
Zitat von: Thorsten Pferdekaemper am 07 August 2019, 19:47:36
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.
Zitat
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 ::))
Zitat
Ü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
Zitat von: loetmeister am 10 August 2019, 12:06:32
Was mir zu dem eigentlich Problem noch aufgefallen ist... (eigentlich keine Überraschung...)
Ja, genau. Deshalb hatte ich ja geschrieben:
Zitat von: Thorsten Pferdekaemper am 07 August 2019, 19:47:36Auß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
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. ;D
Gruß,
Thomas
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
Hi Thorsten,
nein, habe keine Tests mit der CCU gemacht.
Ich habe es erst mal so belassen, das ich alle Aktor und alle Sensor peerings jeweils mit der selben Konfiguration (paramset: address_step, start_address, etc.) anlege.
Das ist auch ok, solange ich nicht verschiedene peering parameter haben möchte. (SHORT_... LONG_... action type) So was 'komisches' habe ich bisher auch nur bei einem Device gemacht... ::)
Ich muss in den nächsten Monaten einen Teil meiner Anlage in betrieb nehmen... da liegt mein Fokus erst mal auf stabile Funktion. Erweitern kann ich dann wieder später... ;)
Gruß,
Thomas
Zitat von: loetmeister am 14 November 2019, 23:12:22
Ich muss in den nächsten Monaten einen Teil meiner Anlage in betrieb nehmen... da liegt mein Fokus erst mal auf stabile Funktion. Erweitern kann ich dann wieder später... ;)
Ok, dann dürfte es auch in Deinem Sinne sein, wenn ich da jetzt nicht drangehe. Das einzubauen wäre nämlich schon eine ziemliche Änderung und würde das ganze definitiv destabilisieren.
Ich lasse also mit den Peerings erst einmal alles so, wie es ist.
Gruß,
Thorsten
Hallo Thorstens,
aus meiner anderen Anfrage, selbes Thema zu Peering Problemen "no free PeerId found".
no free peerIDs (https://forum.fhem.de/index.php?topic=139565.msg1327928#msg1327928)
Besteht die Möglichkeit die Stellen wo "Peerings" gespeichert werden über ein RAW-Befehl zu löschen/zu überschreiben ?
(das Bearbeiten der Haus-Bus-Module selbst (dazu hat Hausbus ein Video gesendet, möchte ich vorerst vermeiden)).
Hallo,
hier eine Frage von Herm. (haus-bus) um mich bei meinem Problem des Peerings der Homebrew-Geräte zu unterstützen.
Wir müssen rausfinden, was FHEM genau davon abhält den Speicher zu verwenden.
Bei Homematic funktioniert ja alles. Wahrscheinlich ist es irgend ein Status, den FHEM anders auswertet.
Am Chip kann es nicht liegen, weil FHEM einfach eine Lese- und Schreibfunktion direkt aufs Eeprom bekommt.
In einem leeren Eeprom stehen normalerweise lautet 0xFF. Vielleicht kann mal jemand aus dem FHEM Forum das vergleichen
oder rausfinden, woran FHEM interpretiert, dass das Eeprom voll ist ?
Könnt Ihr helfen ?
Gruß Jörg
Hi,
also wenn ich das Coding noch richtig verstehe, dann wird in FHEM tatsächlich auf 255 (also 0xFF) abgefragt. Ich bin mir an der Stelle allerdings nicht 1000-prozentif sicher, ob da tatsächlich nur ein Byte aus dem EEPROM geholt wird oder mehr. Das kann ich momentan nicht ganz nachvollziehen.
Vielleicht will sich da jemand mal eine Debug-Ausgabe reinbauen. Das ganze ist in
/opt/fhem/FHEM/lib/HM485/PeeringManager.pm in getFreePeerId:
return $peerId if($chHash->{value} >= 255);
Womöglich ist hier das $chHash->{value} nicht (nur) ein Byte oder wird irgendwie komisch interpretiert. Ich muss aber ehrlich gestehen, dass ich da momentan nicht mehr ganz durchblicke. Ich glaube, dass der CHANNEL-Teil der Verknüpfung abgefragt wird.
Was noch wichtig ist: Im XML muss im "parameset type="LINK"" tag der richtige count stehen. ...sonst klappt das ganze auch nicht.
Gruß,
Thorsten
Hallo Thorsten,
wie ich eine Debug reinbaue - und das dann auswerten soll, weiss ich nicht.
Vielleicht hilft dir diese Info (um es etwas einzugrenzen) weiter.
Ich kann mit Eingängen (Taster) von Originalmodulen die Ausgänge der "homebrew"-Module peeren.
Ich kann mit den Eingängen (Taster) von "homebrew"-Module nichts peeren. Dann kommt so etwas:set peer HBW_LC_SW16_IN8_DR_ESP_HBW0002016_17 no free PeerId found
Gruß Jörg