Hauptmenü

MAXLAN Watchdog

Begonnen von P.A.Trick, 15 April 2014, 19:45:34

Vorheriges Thema - Nächstes Thema

P.A.Trick

Heute ist mein Cube, warum auch immer, nicht mehr mit FHEM verbindbar. Nach einem Reset (Stecker raus) ging alles wieder.
Nun habe ich mir überlegt, einen Watchdog darauf zu setzen. Leider sehe ich das Event nicht im Reading. Kann mir jemand weiterhelfen was ich hier falsch mache?

define watchdog_maxlan_status watchdog MAXLAN.*disconnected 00:05 MAXLAN.*connected {\
if(Value("config_push_active") eq "on") { fhem("set pushmsg msg 'fhem' 'MAX Lan Gateway disconnected!' '' 0 '' \
}                                                     
attr watchdog_maxlan_status regexp1WontReactivate 1     


Device ist wie folgt definiert:
define m1 MAXLAN 192.168.1.17 10
attr m1 group MAX       
attr m1 room _System                 
attr m1 set-clock-on-init 1


Eintrag aus dem FHEM Log
2014.04.15 19:32:00 2: MAXLAN_Connect: Could not connect   

Wie greife ich den Event vom state nun ab?

Vielen Dank für einen Ansatz!


Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

P.A.Trick

Es fehlt scheinbar das Reading "state" im Device MAXLAN. Dies ist wohl der Grund dafür, dass die Statusabfrage nicht funktioniert.
Kann man das reading state dem Device irgendwie als UserReading hinzufügen?
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

jisleib

Die Zeit (timestamp) vom Dutycycle wird ständig aktualisiert. Die sollte für den Wachdog taugen.

P.A.Trick

Danke fuer den Tipp, dennoch fände ich ein State im Reading super! Vielleicht erbarmt sich ja der Modulautor :-)
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

jisleib

kleiner patch.

es sind nur die zwei readingsSingleUpdate Zeilen eingefügt. Ich hab´s mit und ohne "ondemand" getestet.

im Bild sieht man das Ergebnis

ausserdem zeig ich das mit einem

devStateIcon  opened.*:message_socket_on_off connected:message_socket_on_off dis.*:message_socket_off

an.

jisleib

noch ein kleiner Tip
[ORGINAL]
Device ist wie folgt definiert:
define m1 MAXLAN 192.168.1.17 10
attr m1 group MAX       
attr m1 room _System                 
attr m1 set-clock-on-init 1


hier würde ich das so abändern
define m1 MAXLAN 192.168.1.17 60 ondemand
attr m1 group MAX       
attr m1 room _System                 
attr m1 set-clock-on-init 0


mit "ondemand" wird die Verbindung immer nur kurz zum Cube hergestellt. Dadurch hat man die Chance mit anderer Software wie dem MAX Portal oder MAX Buddy auf ihn zuzugreifen. alle 60 Sekunden sollte eine Abfrage auch ausreichen.

die letzte Zeile nur wenn der Cube mit dem MAX-Portal verbunden ist auf 0 setzen, dann wird er durch das Portal immer mal wieder zeitlich syncronisiert.

Grüße

P.A.Trick

Danke das hatte ich mittlerweile schon gemacht.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

P.A.Trick

Zitat von: Jürgen I. am 21 April 2014, 19:44:42
kleiner patch.

es sind nur die zwei readingsSingleUpdate Zeilen eingefügt. Ich hab´s mit und ohne "ondemand" getestet.

im Bild sieht man das Ergebnis

ausserdem zeig ich das mit einem

devStateIcon  opened.*:message_socket_on_off connected:message_socket_on_off dis.*:message_socket_off

an.

Super Danke, nur weiß ich nicht wie man den Patch anwendet?
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

jisleib

ich habe auch kein Tool dafür. Eigentlich müssen nur die Codezeilen an die davor angegebenen Zeilen.

die gepatchte Datei hängt mit an.


P.A.Trick

#9
Danke habe es eben eingespielt und funktioniert.
Wäre es denn möglich die Änderung offiziell einzuchecken?

EDIT:

Kannst du das "connected" noch durch "opened" tauschen? Dann hält sich das Modul an den Standard. Danke!
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

jisleib

#10
wo finde ich diese Guidelines/Standards ? Für mich bedeutet "opened" eher sowas wie disconnected (Offene Verbindung).

Ich kann die Änderungen nicht einchecken, da müsste man dann Matthias Gehre den Modulentwickler fragen. Momentan helfe ich mir damit das ich die beiden Module MAX und MAXLAN vom Update ausschliese und ab und an schaue ob sich was zu meinem Modul geändert hat und pflege das dann nach. Wenn sich meine Änderungen nach ein paar Tagen oder Wochen nicht negativ auswirken gibts einen patch für den Entwickler den er dann meist so einpflegt.

Gruß Jürgen

EDIT:
in Zeile 800 steht das "connected".  Einfach mit einem Editor ändern, z.B. Notepad++

P.A.Trick

Hm finde jetzt den Thread leider nicht mehr, auf jedenfall war das im Zusammenhang mit XBMC.
Ein

list state=disconnected liefert bei mir keine Ergebnisse! Sorry.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

riker1

Hallo,

ich habe das gleiche Problem.

der MaxCube meldet sich immer mal wieder ab ohne das man es merkt.

Status ist dann immer noch opened.

ein set maxcube reconnect hilft auch nicht.

Pingbar ist der dann noch.

Nur ein Strom Power-Reset hilft.

Eine Andere Anwendung greift nicht auf den MaxCube zu.


Hat da jemand eine Lösung - Ursache?

Danke T
FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox

Maui

Kenne den cube nicht, nur den selbstbau cul aber da ist für sowas häufig falsches netzteil, schlechtes Kabel der Grund. Weiss allerdings nicht ob der cube evtl ein eigenes Netzteil hat.
Ansonsten (mit kanonen auf Spatzen) könntest du den cube mit einer wlan steckdose neustarten, wenn der sich weg hängt.

riker1

Hallo,

danke. ja der Cube hat ein eigenes Netzteil.

Das mit der Wlan Dose werde ich mal anpacken.

Danke
FHEM    5.26.1 Ubuntu 18, FHEM    5.26.1 RPI 3 , Actoren: IT ,Tasmota, ESPEasy,
MAX CUBE, MAX HT, MAX WT, Selbstbau nanoCULs, FS 20,Tasmota, Homematic, FTK, SW. DIM, Smoke,KODI,Squeezebox