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:
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:
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:
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?
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ß?
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?
Zitat von: fallenguru am 07 Februar 2015, 16:51:55
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?
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.
Zitat von: krikan am 07 Februar 2015, 17:38:45Die 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.
Zitat von: klaus.schauer am 07 Februar 2015, 17:58:07
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! 8)