Broadcast time - Häufigkeit verringern

Begonnen von walterschmitz, 19 Januar 2019, 11:24:47

Vorheriges Thema - Nächstes Thema

walterschmitz

Hallo zusammen,

mein CUL868 senden über den CULMAX an die MAX Devices recht häufig aus meiner Sicht die Zeit als Broadcast. In meinem Log-File über die Dauer von ca 7 Minuten wurde 6x die Meldungen verzeichnet Broadcast time to xyz verzeichnet. Meiner Meinung einfach zu häufig.

Kann man einstellen, dass das z.B. nur 1x in der Stunde oder noch weniger passiert... damit würde ich die Credits weniger häufig verbrauchen und hätte mehr Credits für "richtige" Device-Umstellungen / -einstellungen.

Ist gerade in dem Moment etwas blöd, wenn man Devices Resetten musste bzw. neu anlernen möchte... da kommt man mit 100 oder weniger Credits nicht so richtig weit... und das meiste davon wird bei mir vom Broadcast verbraucht, weil sonst nicht so oft was gesendet werden muss.

Evtl. reicht es auch, dass nur temporär geändert wird sofern das Broadcast wichtig ist für andere Einstellungen / Funktionen, die mir gerade nicht klar sind oder einfallen würden.

Danke für einen Einstellungstipp.

Gruß

Wzut

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

Kenn ich den Thread.
Aber soweit ich das gelesen habe, gab es da keine richtige Lösung.
oder hab ich da was übersehen.

Ich schau mir den Thread gleich gerne nochmal genauer an, nur um auszuschließen, dass nicht doch eine Lösung beschrieben ist.

Wzut

Seite 2 , Antwort #22 hängte ne neue CUL_HM an
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

walterschmitz

okay. ich habe die mal runtergeladen, und in /opt/fhem/FHEM/14_CUL_MAX.pm kopiert bzw. die Datei dort ersetzt.
Dann habe ich shutdown restart durchgeführt und schaue mal, was sich ändert.

Habe das ganze aber so aufgefasst, als sei das eine Test-Datei... und irgendwann wird das ganze in einem Update ausgerollt... daher hab ich das nicht reinkopiert.

walterschmitz

#5
Hallo zusammen,

habe jetzt schon 2x gehabt, dass ich folgende Eintrag im LOG gefunden habe und danach anscheinend FHEM gestoppt wurde.
2019.01.27 06:00:36 5: CULMAX: dispatch MAX,0,ThermostatState,0e225f,382A2A00CB
2019.01.27 06:00:36 5: MAX_Parse MAX,0,ThermostatState,0e225f,382A2A00CB
2019.01.27 06:00:36 5: battery 0, rferror 0, panel 1, langateway 1, dstsetting 1, mode 0, valveposition 42 %, desiredTemperature 21, until , curTemp 20.3
2019.01.27 06:00:37 5: CULMAX: dispatch MAX,0,ThermostatState,08d15f,581E2A00CC
2019.01.27 06:00:37 5: MAX_Parse MAX,0,ThermostatState,08d15f,581E2A00CC
2019.01.27 06:00:37 5: battery 0, rferror 1, panel 0, langateway 1, dstsetting 1, mode 0, valveposition 30 %, desiredTemperature 21, until , curTemp 20.4
Can't use an undefined value as a HASH reference at ./FHEM/14_CUL_MAX.pm line 367.


zwischen 06:00 Uhr und 19:31 Uhr war FHEM down :-(
War die letzten 2 Tage so... ich werde die nächsten Tage mal vermehrt drauf achten und entsprechend die Logs vor dem Absturz kurz begutachten, sobald mir es auffällt.

Blöd, wenn man das nicht merkt und dann MAX-Elemente nicht mehr richtig arbeiten bzw. Lichter nicht geschaltet werden.

Was kann man da machen?

walterschmitz

#6
Zwischenzeitlich erneut 2x ist FHEM abgestürzt:

heute leider nicht aufgefallen... aber die letzte Meldung war wohl von Gestern in der Log:
019.01.29 12:02:44 2: Got message for undefined device 112180, and failed to guess type from msg 'Ack' - ignoring
Can't use an undefined value as a HASH reference at ./FHEM/14_CUL_MAX.pm line 367.


Anscheinend bleibt CUL_MAX.pm immer an der gleichen Stelle hängen :-(

Das Device 112180 ist in meiner FHEM.cfg nicht enthalten. Augenscheinlich nutzt im Haus noch jemand MAX-Elemente, die meinen FHEM zum Absturz bringen.
Das Device 08d15f gehört zu mir und ist ein HeatingThermostat (HT+).

Kann mir jemand weiterhelfen?

walterschmitz

heute hat mich wieder ein Shutdown ereilt :-(
2019.01.31 06:03:31 2: Got message for undefined device 112180, and failed to guess type from msg 'Ack' - ignoring Can't use an undefined value as a HASH reference at ./FHEM/14_CUL_MAX.pm line 367.

Da 112180 nicht von mir ist, kann ich nicht mal was machen :-( oder hat jemand eine Idee? ich habe Autocreate nicht aktiv, aber trotzdem crashed der 112180 vom Nachbarn immer wieder mein FHEM :-(
Bin schon etwas genervt.

Wzut

Ich würde zuerst mir ein MAX Device mit der ID 112180 mit irgendeinem Typ anlegen und es sofort auf ignore setzen.
Danach emtweder wieder die alte CUL_MAX verwenden oder in der neuen die besagte Zeile 367 auskommentieren ( ist nur eine Log Ausgabe )
Log3 $shash, 1, "CUL_MAX_Parse: Got TimeInformation sent from '".CUL_MAX_DeviceHash($src)->{NAME}."' to '".CUL_MAX_DeviceHash($dst)->{NAME}."': (in GMT) year $year, mon $month, day $day, hour $hour, min $min, sec $sec, unk ($unk1, $unk2, $unk3)";

Als nächstes würde ich Reinerlein anschreiben und ihn auf das Problem aufmerksam machen, ich könnte wetten er hatte unbekannte Geräte nicht auf dem Radar.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher