Opus greenNet 561.135 (~K&B MD15-FTL-HE) -- zwei "Geräte" / IDs?!?

[fallenguru]

Morgen!

Neulich ist mir ein Opus greenNet 561.135 verstorben, gab von einem Tag auf den nächsten keinen Piep mehr von sich. Von diesem Modell habe ich nun das zweite Jahr sechs Stück im Dienst, es handelt sich um OEM Kieback & Peter MD15-FTL-HE.

Hier ein seit jeher Funktionierendes:

Code Auswählen Erweitern


Internals:
   DEF        0084580C
   IODev      rocket
   LASTInputDev rocket
   MSGCNT     3
   NAME       ha_GZ
   NR         185
   NTFY_ORDER 50-ha_GZ
   STATE      T_ist: 20.4 °C; T_soll: 20.5 °C; V: 50 %
   TYPE       EnOcean
   rocket_DestinationID 018298B0
   rocket_MSGCNT 3
   rocket_PacketType 1
   rocket_RSSI -65
   rocket_ReceivingQuality excellent
   rocket_RepeatingCounter 0
   rocket_SubTelNum 6
   rocket_TIME 2015-02-07 12:07:28
   Readings:
     2015-01-07 12:18:41   CMD             desired-temp
     2014-01-24 14:32:26   actuator        0
     2015-02-07 12:07:28   actuatorStatus  ok
     2015-02-07 12:07:28   battery         ok
     2015-02-07 12:07:28   cover           closed
     2015-02-07 12:07:28   currentValue    50
     2015-01-07 12:18:41   desired-temp    20.5
     2015-02-07 12:07:28   energyInput     disabled
     2015-02-07 12:07:28   energyStorage   empty
     2015-02-07 12:07:28   last_desired_temp 20.5
     2015-02-07 12:07:28   measured-temp   20.4
     2015-02-07 12:07:28   selfCtl         off
     2015-02-07 12:07:28   serviceOn       no
     2015-02-07 12:07:28   state           50
     2014-01-24 14:31:22   teach-in        EEP A5-20-01 Manufacturer: Kieback + Peter
     2015-02-07 12:07:28   tempSensor      ok
     2015-02-07 12:07:28   temperature     20.4
     2015-02-07 12:07:28   window          closed
Attributes:
   IODev      rocket
   alias      [GZ] Ventilstellantrieb
   comMode    biDir
   destinationID unicast
   group      Klima
   manufID    00A
   room       GrünesZimmer,System
   stateFormat T_ist: measured-temp °C; T_soll: desired-temp °C; V: currentValue %
   subDef     00000000
   subType    MD15
   userReadings last_desired_temp:currentValue.* { ReadingsVal("ha_GZ","desired-temp",0) }


Nun habe ich Ersatz bekommen, selbe Modellnummer, sieht identisch aus &c. Erster Versuch war: Fhem beenden. ID in der fhem.cfg von alt auf neu (lt. Kleber außen) ändern; Fhem starten. Aktor neu einlernen. Geht so weit -- die angezeigte Temperatur ist noch zu hoch, aber das mag an der Motor-Orgie während der Initialisierung liegen:

Code Auswählen Erweitern


CMD        desired-temp
   DEF        008459DD
   IODev      rocket
   LASTInputDev rocket
   MSGCNT     12
   NAME       ha_BZ
   NR         242
   NTFY_ORDER 50-ha_BZ
   STATE      T_ist: 19.5 °C; T_soll: 16 °C; V: 0 %
   TYPE       EnOcean
   rocket_DestinationID 018298B0
   rocket_MSGCNT 12
   rocket_PacketType 1
   rocket_RSSI -74
   rocket_ReceivingQuality excellent
   rocket_RepeatingCounter 0
   rocket_SubTelNum 6
   rocket_TIME 2015-02-07 12:54:04
   Readings:
     2015-02-07 12:26:27   CMD             desired-temp
     2015-01-26 16:15:32   actuator        0
     2015-02-07 12:54:04   actuatorStatus  ok
     2015-02-07 12:54:04   battery         ok
     2015-02-07 12:54:04   cover           closed
     2015-02-07 12:54:04   currentValue    0
     2015-02-07 12:26:27   desired-temp    16
     2015-02-07 12:54:04   energyInput     disabled
     2015-02-07 12:54:04   energyStorage   empty
     2015-02-07 12:54:04   last_desired_temp 16
     2015-02-07 12:54:04   measured-temp   19.5
     2015-02-07 12:54:04   selfCtl         off
     2015-02-07 12:54:04   serviceOn       no
     2015-02-07 12:54:04   state           0
     2015-02-07 12:03:32   teach-in        EEP A5-20-01 Manufacturer: Kieback + Peter
     2015-02-07 12:54:04   tempSensor      ok
     2015-02-07 12:54:04   temperature     19.5
     2015-02-07 12:54:04   window          closed
Attributes:
   IODev      rocket
   alias      [BZ] Ventilstellantrieb
   comMode    biDir
   destinationID unicast
   eep        A5-20-01
   group      Klima
   manufID    00A
   room       BlauesZimmer,System
   stateFormat T_ist: measured-temp °C; T_soll: desired-temp °C; V: currentValue %
   subDef     00000000
   subType    hvac.01
   userReadings last_desired_temp:currentValue.* { ReadingsVal("ha_BZ","desired-temp",0) }


Nur legt mir Autocreate beim Teach-in aber ein zusätzliches Gerät an, offensichtlich auch ein "hvac.01", mit einer ID, die am Gerät nicht aufscheint:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        018298B0
   IODev      rocket
   LASTInputDev rocket
   MSGCNT     67
   NAME       EnO_sensor_018298B0
   NR         603
   NTFY_ORDER 50-EnO_sensor_018298B0
   STATE      114
   TYPE       EnOcean
   rocket_DestinationID 008459D9
   rocket_MSGCNT 67
   rocket_PacketType 1
   rocket_RSSI -83
   rocket_ReceivingQuality good
   rocket_RepeatingCounter 1
   rocket_SubTelNum 3
   rocket_TIME 2015-02-07 13:00:36
   Readings:
     2015-02-07 13:00:36   actuatorStatus  ok
     2015-02-07 13:00:36   battery         low
     2015-02-07 13:00:36   cover           closed
     2015-02-07 13:00:36   currentValue    114
     2015-02-07 13:00:36   energyInput     disabled
     2015-02-07 13:00:36   energyStorage   empty
     2015-02-07 13:00:36   measured-temp   0.6
     2015-02-07 13:00:36   selfCtl         off
     2015-02-07 13:00:36   serviceOn       yes
     2015-02-07 13:00:36   state           114
     2015-02-07 12:03:53   teach-in        EEP A5-20-01 Manufacturer: Multi user Manufacturer ID
     2015-02-07 13:00:36   tempSensor      failed
     2015-02-07 13:00:36   window          open
Attributes:
   IODev      rocket
   comMode    biDir
   destinationID unicast
   eep        A5-20-01
   manufID    7FF
   room       autocreate
   subDef     00000000
   subType    hvac.01


"Beide" Geräte senden regelmäßig, aber nicht gleichzeitig. Das von Autocreate angelegte liefert offensichtlich falsche Werte. Es dürfte irgendeinen Zusammenhang über  rocket_DestinationID geben ...

Ich werde das jetzt beobachten. Wenn sich das reguläre Device normal verhält, kann ich das Phantom ja einfach löschen, trotzdem würde mich interessieren, was da abgeht. Ideen?

[klaus.schauer]

Bidirektionale A5-Aktoren immer, auch bei einem Geräteaustausch, per teach-in einlernen. Sonst stimmt die SenderID im Aktor nicht. Warum der mühsame Umweg zu Fuß?

[fallenguru]

Hauptsächlich, weil ich mit dem alten Gerät Jahre an Logs habe und gern hätte, dass der Ersatz genau dort weiterloggt. Wenn ich Autocreate ein neues Gerät anlegen lasse, dann generiert das wieder neue Logs unter dem Default-Namen. Was weiß ich, was passiert, wenn ich das Gerät jetzt auf den alten Namen umbenenne ... --> reine Vorsicht gekoppelt mit Fhem-Unkenntnis, sorry.

Einen Teach-in hab' ich natürlich trotzdem gemacht, sonst wäre der neue MD15 ja nicht gepaired?
(Bisher war es nie ein Problem das Teach-in auch bei einem schon definierten Gerät zu machen. Manchmal verlieren die Dinger nämlich die Verbindung und gehen dann in einen autonomen Modus. Da Fhem nur sendet, unmittelbar nachdem es der MD15 tut, baut sich die auch von selbst nicht wieder auf. Vielleicht wär ein keep alive nicht schlecht.)

Wie ist denn die "offizielle" Ersatzprozedur? Altes Gerät löschen, neues Gerät per Autocreate anlernen, umbenennen, attrs alle wieder setzten klingt komplizierter, als schnell im Editor die ID zu ändern und ein Teach-in laufen zu lassen.
Das neue MD15 verhält sich jetzt jedenfalls wie die anderen 5, liefert Daten, reagiert auf Kommandos, list-Ausgabe so weit "gleich". Das von Autocreate angelegte Phantom-MD15 hab ich inzwischen gelöscht.  Was kann denn passieren, wenn ich das jetzt so lasse?

[krikan]

Manchmal verlieren die Dinger nämlich die Verbindung und gehen dann in einen autonomen Modus. Da Fhem nur sendet, unmittelbar nachdem es der MD15 tut, baut sich die auch von selbst nicht wieder auf. Vielleicht wär ein keep alive nicht schlecht.

Das habe ich noch nie erlebt, seitdem der MD15 in Fhem implementiert ist. Die MD15 laufen problemlos und finden auch nach einem Batteriewechsel den Kontakt zu Fhem wieder. Vermute eher, das Du ein Funkproblem hast (Repeater einsetzen). Warum sollte ein Keep-Alive eingebaut werden, dass kannst Du doch selbst durch einen watchdog oder notify?

[klaus.schauer]

Bei diesem Typ von bidirektionaler Kommunikation kann Fhem nur auf ein Telegramm des Aktors warten und dann sofort antworten; eine Überwachung des Aktors (keep alive) bringt deshalb nichts.

Ich baue seit Monaten - da wo es eben geht - zusätzliche automatische Funktionen ein, um die Handarbeit und die Fehlerquellen zu minimieren. Wer es trotzdem zu Fuß machen will...

Beim MD15 geht es nicht zu Fuß. Beim teach-in lernt der Aktor die Fhem SenderID ein, die beim teach-in generiert wird. Die Fhem SenderID eines vorherigen teach-in geht dabei verloren. Also
- alten Aktor aus Fhem löschen,
- neuen Aktor anlernen,
- ggf. Aktor umbenennen und vorher gesicherte Attribute wieder zuweisen,
- bei Bedarf kann man die Log-Dateien auch vorher sichern oder umkopieren.

Na ja, vielleicht findet doch jemand eine zu-Fuß-Variante, die irgendwie geht. Viel Spaß dabei.

[fallenguru]

Die MD15 laufen problemlos und finden auch nach einem Batteriewechsel den Kontakt zu Fhem wieder. Vermute eher, das Du ein Funkproblem hast (Repeater einsetzen). Warum sollte ein Keep-Alive eingebaut werden, dass kannst Du doch selbst durch einen watchdog oder notify?

Ja, manchmal ist der Empfang nicht so hundertprozentig -- wenn dann Fhem auch noch zum falschen Zeitpunkt unten ist (update, Komplettbackup -- Raspberry Pi sind laangsam), sind mir ein paarmal MD15 auf Solo-Betrieb gegangen (so 3x in 2 Jahren bei 6 Geräten). Lt. Anleitung sollte sich das wieder geben, wenn der "Funkpartner" wieder erreichbar ist, tut es aber nicht. Ist ja kein Problem, das manuell wieder einzuränken, v.a., wenn man bedenkt, was EnO Repeater kosten.

[fallenguru]

Ich baue seit Monaten - da wo es eben geht - zusätzliche automatische Funktionen ein, um die Handarbeit und die Fehlerquellen zu minimieren. Wer es trotzdem zu Fuß machen will...

Jemminee, da hab ich ein schönes Fettnäpfchen erwischt! Es soll gesagt sein, dass ich es toll finde, was Du Dir hier alles an Arbeit antust! Ohne Dich hätten wir hier quasi weder Licht noch Heizung ...

Die Kehrseite davon ist, dass die Anforderungen an die Stabilität und Verfügbarkeit des Systems (d. h., von meiner Frau ^^) extrem hoch sind, d. h. regelmäßige Backups auf verschiedenen Ebenen, Ersatzhardware vor Ort -- und, nach den ersten paar Unfällen, abgeschaltetes Autosave und schreibgeschützte fhem.cfg. Wenn ich etwas ändere, dann immer in der laufenden Instanz, dann wird eine Weile beobachtet. Wenn alles passt, schreib ich die fhem.cfg unter anderem Namen raus und generier mir draus einen Patch für die echte (bzw. die passende include-Datei). Dafür, dass Autosave ab einer gewissen Komplexität (includes, wildcards &c.) nicht mehr mitkommt bzw. ich lieber in emacs arbeite, als in einem Webbrowser, kannst Du echt nix!