HM-ES-PMSw1-Pl bringt am HMLan Overload

Begonnen von Stefan M., 01 Juni 2016, 22:09:40

Vorheriges Thema - Nächstes Thema

Otto123

#15
Zitat von: MaJu am 03 Januar 2017, 19:36:17
Wenn ich die Steckdose oder einen Fenstersensor an FHEM anlerne, ist das doch in beiden Fällen "pairen". Ziehe ich nun bei meinem RPi den Stromstecker und öffne anschließend das Fenster mit dem Sensor, leuchtet beim Fenstersensor die LED nicht grün, sondern rot! Läuft FHEM, leuchtet die LED am Fenstersensor grün. Daraus schließe ich, dass FHEM eine Bestätigung sendet und der Fenstersensor diese verarbeitet (Bestätigung da = grün; keine Bestätigung nach mehrmaligem Senden = rot).
Das ist bei mir nicht so! Gerade probiert. Der gepairte oder ungepairte leuchtet nach der Betätigung grün.
Gib mal bitte ein List von dem Fenstersensor der diese Verhalten bringt.

Die Sensoren senden einfach ihre Daten, die erwarten nichts. Nachtrag: die angelernten Sensoren fordern einen ack.
Du kannst einen Temp Sensor kaufen mit Batterien bestücken und hinlegen. Nach wenigen Minuten hast Du help me Messages in deinem Log (oder Readings in der VCCU) und die beiden wissen nichts von einander.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

ZitatDie Sensoren senden einfach ihre Daten, die erwarten nichts
nein. die fordern ein ack.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MaJu

@frank: deine Antwort hatte ich missverstanden (als "erste Antwort auf DEINE Frage", nicht auf "erste Antwort des Threads"). Danke für "nachbohren".

Die Lösung alle thresholdregister in chn2 auf unused
--> wie wird die gesetzt?
Erlebnisreiche Grüße aus Leipzig!

Otto123

#18
Zitat von: frank am 03 Januar 2017, 19:52:11
nein. die fordern ein ack.
Also mein Fenstersensoren fordern nichts. Ich kann es nicht anders sagen. Ich habe es gerade nochmal probiert. Nachtrag: Der HMLAN liefert selbständig das ack
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

wie jedes register mit regset, zb
set <chn2> regSet txThrCur unused

hier auch ein test von mir, vielleicht kann otto sich noch erinnern. https://forum.fhem.de/index.php/topic,61224.msg526651.html#msg526651

@otto
hier geht es nicht um fenstersensoren, ich meine die messsteckdosen. 
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Otto123

Zitat von: frank am 03 Januar 2017, 20:10:39
@otto
hier geht es nicht um fenstersensoren, ich meine die messsteckdosen.
Nicht nur MaJu hat von Fenstersensoren geredet.  ;)

Ja aber schon klar, ich kann mich erinnern. Ich hatte damals das Prinzip verstanden, dass jedoch diese Werte ein ack fordern war mir da nicht so bewusst geworden.
Und ich dachte irgendwie, die Register sind pro peer gesetzt. Ist der _Pwr Channel intern gepeert?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

@otto
wenn dein fk grün leuchtet muss auch dieser ein ack bekommen haben, woher auch immer. hmlan, hmusb senden solche ack autonom. um diese ack's zu sniffen braucht man allerdings ein 2. io.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Otto123

Zitat von: frank am 04 Januar 2017, 09:22:59
@otto
wenn dein fk grün leuchtet muss auch dieser ein ack bekommen haben, woher auch immer. hmlan, hmusb senden solche ack autonom. um diese ack's zu sniffen braucht man allerdings ein 2. io.
Guten Morgen,

sorry sorry sorry - da habe ich mich aber schön blamiert!  :-[
Tatsächlich der HMLAN sendet selbständig ack sobald er von FHEM mal initialisiert wurde und am Strom bleibt obwohl FHEM dann aus ist. Das war mein Fehler: ich habe den raspberry mit dem HM-RPI Modul zwar vom Netz genommen aber der HMLAN war weiter aktiv.
Da sich das blinkern nicht  von dem unterscheidet, wenn der Fenstersensor nicht angelernt ist, dachte ich das muss so ...

Na mal gut, dass Du mit mir immer so hartnäckig bist!  :D

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

ZitatNa mal gut, dass Du mit mir immer so hartnäckig bist!
du willst es ja auch wirklich wissen und in der regel profitiert sogar das wiki davon.  ;)

ZitatTatsächlich der HMLAN sendet selbständig ack sobald er von FHEM mal initialisiert wurde und am Strom bleibt obwohl FHEM dann aus ist.
sicherlich die devices, die man mit "get <hmlan> assignIDs" erhält.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MaJu

Danke für die Anregungen. Anbei die von mir durchgeführte Lösung, falls noch jemand anderes danach sucht.

Hintergrund:
Ich biete Segway-Touren in Leipzig an. Bei Segways darf das Kaltgeräte-Kabel nicht unter Spannung stehen, wenn es in den Segway ein- oder ausgesteckt wird (der Spannungsbogen führt sonst auf Dauer zum Ausfall der sehr empfindlichen Ladegeräte). Bisher hatte ich mehrere Geräte an einer Schaltersteckdosenleiste und habe diese immer zentral abgeschaltet wenn ich Segways an- oder abgesteckt habe. Manchmal habe ich zwar die Kabel alle eingesteckt, aber einfach vergessen, die Steckdosenleiste einzuschalten. Das ist fatal, denn durch den Alarm-Modus zur Diebstahlsicherung geht der Akku auch runter, so dass die Fahrzeuge am Folgetag nicht zur Verfügung stehen. Bisher ist mir das zum Glück noch nie passiert, wenn es drauf ankam - aber darauf will ich nicht warten.

Um das zu vermeiden, hängt nun jeder Segway an einer eigenen Homematic-Steckdose mit Leistungsmessung. An der Wand ist nun ein Tablet, an dem ich die Steckdosen einzeln schalten kann. Dabei gibt es immer ein optisches Feedback: Steckdose ist aus, Steckdose ist an aber es ist kein Stecker gesteckt (Verbrauch kleiner 1 W bei Status "an"), Fahrzeug lädt, Fahrzeug voll (Verbrauch kleiner 40 W).

Mit einem DOIF werte ich die Messwerte und Schaltzustände aus, lasse es über eine Readingsgroup anzeigen bzw. schalte damit auch.

Wer es mal sehen möchte: Das Tablet hängt bei mir im Laden in der Leipziger Innenstadt auf der linken Seite. Mit AMAD schalte ich das Display bei Abwesenheit jedoch aus.

Da die Segways einen SEHR schwankenden Lade-Energieverbrauch haben, haben die Steckdosen alle jeweils im standardmäßig gesetzten Rhytmus von 8 Sekunden neue Werte gesendet, da die Schwellwerte im Standard sehr niedrig eingestellt sind. Das führte allein durch die Steckdosen zu 3.150 Sendungen je Stunde (7 Stk x je 450), die vom HMUSB mit einer Bestätigungsmeldung beantwortet werden müssen. Dadurch kam es immer zum Overload. Neben den fehlenden Bestätigungen konnten somit auch keine Schalt-Befehle mehr an andere Geräte übermittelt werden.

Mit den folgenden FHEM-Befehlen habe ich bei den Steckdosen HM-ES-PMSw1-Pl alles deaktiviert was ich nicht brauche:set Steckdose_[1-7]_Pwr regSet txThrCur 0
set Steckdose_[1-7]_Pwr regSet txThrFrq 0
set Steckdose_[1-7]_Pwr regSet txThrVlt 0


mit den folgenden Befehlen habe ich das Sendeintervall auf 1 Sekunde verkürzt, um Änderungen schneller auf dem Tablet zu sehen. Jedoch werden Änderungen nun erst ab 40 Watt Änderung unmittelbar übermittelt:set Steckdose_[1-7]_Pwr regSet txMinDly 1
set Steckdose_[1-7]_Pwr regSet txThrPwr 40


Anschließend noch bei allen Steckdosen die Daten neu auslesen, damit es in FHEM hübsch aussieht:set Steckdose_[1-7]_Pwr getConfig
Erlebnisreiche Grüße aus Leipzig!