Homebrew Devices, XML und anlegen von peerings

[loetmeister]

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

[Thorsten Pferdekaemper]

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

[Treibhaus]

Hallo Thorstens,

aus meiner anderen Anfrage, selbes Thema zu Peering Problemen "no free PeerId found".
no free peerIDs

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)).

[Treibhaus]

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

[Thorsten Pferdekaemper]

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:

Code Auswählen Erweitern

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

[Treibhaus]

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:

Code Auswählen Erweitern

set peer HBW_LC_SW16_IN8_DR_ESP_HBW0002016_17 no free PeerId found
Gruß Jörg