JSON: Wie den Inhalt aus HSBColor in 3 Readings ?

Begonnen von TomLee, 25 Februar 2020, 18:48:40

Vorheriges Thema - Nächstes Thema

TomLee

Ok, das mit jsonMap hat sich ja geradebgeklärt. Jetzt verstehe ich es auch.



Zu dem zweiten Wert in HSBColor nochmal (erster Post der JSON), wenn ich mich da wirklich dran machen wollte.
Das mach ich genau so mit regexp wie bei WLED, richtig.
Darum hast du auf die Beispiele in den Templates verwiesen, weil es keine Funktion gibt die mir diesen Wert zurückgeben wird.

Beta-User

Zitat von: TomLee am 03 März 2020, 13:27:11
Zu dem zweiten Wert in HSBColor nochmal (erster Post der JSON), wenn ich mich da wirklich dran machen wollte.
Das mach ich genau so mit regexp wie bei WLED, richtig.
Darum hast du auf die Beispiele in den Templates verwiesen, weil es keine Funktion gibt die mir diesen Wert zurückgeben wird.
Genau  ;) .

Es gilt aber weiter:
Zitat von: Beta-User am 28 Februar 2020, 09:50:36
Allerdings gibt es z.B. in Color.pm keine Routinen, die viel mehr hergeben als eine RGB-Umrechnung, und dann kann man auch gleich dieses Datenfeld nehmen (und mit jsonMap "richtig" benennen)...
Gemeint war: Du kannst dann auch gleich das rgb-Datenfeld nehmen, das wird ja direkt umgerechnet im JSON geliefert; die drei Angaben für HSBColor1 sind m.E. nur eine andere Darstellung, aber nicht wirklich ein inhaltlicher Mehrwert... (Aber mach' ruhig, zum Lernen ist das sicher eine gute Idee, jetzt liegen ja die Bausteinchen alle auf dem Tisch :) .)

Zu dem noch:
Zitat von: TomLee am 01 März 2020, 20:49:39
Eine Verständnisfrage noch:

Wozu eigentlich im Template  BASE_ID/DEVNAME/v:.* api abonnieren ?

Kein User braucht doch dieses Reading.
Kann ich gerne ausbauen, es war allerdings wohl scheinbar übergangsweise sinnvoll, um die weitere Auswertung zu ermöglichen wie jetzt geschehen.
Bitte um ein Signal dazu...



OT: Im Entwicklerbereich habe ich vorhin was zur Spracherkennung+Sensoren gepostet. Vielleicht magst du testen und in "unserem" Spracherkennungs-Thread Rückmelden, ob das funktioniert?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

Einen Mehrwert für das Template sehe ich schon.

Mit saturation:colorpicker,BRI,0,1,100 cmnd/tasmota/HSBCOLOR2 kann man die Sättigung schon setzen, bloss kommt halt nicht HSBCOLOR2 zurück. Der Wert steht ja aber an der zweiten Stelle in HSBColor.

Wenns mich packt versuch ich es umzusetzen.




Ich denke irgendwann wird bei WLED auch auch ein JSON zurückgegeben, solange gibt es jetzt ein Beispiel wie man mit dem XML umgehen kann, darum drin lassen.




Natürlich hab ich das gelesen, interessiert mich auch sehr, schau ich mir auf jedenfall abends mal an.

Beta-User

OK, dann macht das (viel) Sinn, war wohl wegen der Benennung mit HSBColor_x etwas abgelenkt...

Für Stufe 3 dann noch: Die Readings möglichst nur updaten, wenn was geändert ist, und im Hinterkopf behalten, dass der Rückgabehash auch mehrere key/value-Paare enthalten kann (siehe json2nameValue). Würde evtl. Sinn machen, das in eine Sub auszulagern, die man aus svn-contrib holt, wenn man sie braucht?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

{"POWER1":"on","Dimmer":12,"Color":"1A1E1F","HSBColor":"189,17,12","Channel":[10,12,12]}




Hab mich ehrlich gesagt noch nie so richtig mit regexp beschäftigt, den fertigen Ausdruck zu WLED findet man unter den ersten Ergebnissen einer Googlesuche, das war kein Problem  :P

Kann man es so machen, ist es denn wirklich so einfach ?

stat/tasmota/RESULT:.* { $EVENT =~ m,(\d+)\,(\d+)\,(\d+), ? $2 eq ReadingsVal($NAME,"saturation","unknown") ? undef :{"saturation"=>"$2"} : undef }

Mit diesem regexp gibts zwei Matches à drei Groups, spricht was dagegen ?

oder besser

"(HSBColor)":"(\d+),(\d+),(\d+)"

damit wärs weiter eingegrenzt, mit nur einem Match à 4 Groups.

Allerdings komm ich nicht drauf wie ich das einbaue, weil wegen der " immer gemeckert wird:

stat/tasmota/RESULT:.* { $EVENT =~ m,\\"(HSBColor)\\":\\"(\d+),(\d+),(\d+)\\", ? $2 eq ReadingsVal($NAME,"saturation","unknown") ? undef :{"saturation"=>"$2"} : undef }

Beta-User

Du bist nahe dran...

Ich bevorzuge die eindeutige Variante und versuche, "schwierige" Zeichen eher zu vermeiden. Das ergäbe (ungetestet):

$EVENT =~ m/HSBColor...(\d+),(\d+),(\d+)/
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

So klappts, Danke.

stat/tasmota/RESULT:.* { $EVENT =~ m,HSBColor...(\d+)\,(\d+)\,(\d+), ? $2 eq ReadingsVal($NAME,"saturation","unknown") ? undef :{"saturation"=>"$2"} : undef }

Wenn ich jetzt die saturation ändere, gibt es ein Event bei rgb und saturation.
Ändere ich pct gibt es ein Event bei rgb und pct.
Ändere ich rgb gibt es ein Event bei rgb und saturation.

Das verstehe ich noch nicht, in dem Json sind doch immer alle drei Werte folglich müsste es doch 3 Events bei einer Änderung geben.


defmod MQTT2_DVES_0C7A27 MQTT2_DEVICE DVES_0C7A27
attr MQTT2_DVES_0C7A27 IODev MQTT2_Server
attr MQTT2_DVES_0C7A27 autocreate 0
attr MQTT2_DVES_0C7A27 comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/cmnd/tasmota/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.\
\
stat/tasmota/RESULT:.* { $EVENT =~ m,(\d+)\,(\d+)\,(\d+), ? $2 eq ReadingsVal($NAME,"saturation","unknown") ? undef :{"saturation"=>"$2"} : undef }
attr MQTT2_DVES_0C7A27 devStateIcon {Color::devStateIcon($name,"rgb","Color","pct","state")}
attr MQTT2_DVES_0C7A27 event-on-change-reading .*
attr MQTT2_DVES_0C7A27 genericDeviceType light
attr MQTT2_DVES_0C7A27 icon hue_filled_outlet
attr MQTT2_DVES_0C7A27 jsonMap POWER1:0 Dimmer:pct Channel_1:0 Channel_2:0 Channel_3:0 HSBColor:0 Color:rgb
attr MQTT2_DVES_0C7A27 model tasmota_rgbw_led
attr MQTT2_DVES_0C7A27 readingList tele/tasmota/LWT:.* LWT\
  tele/tasmota/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/tasmota/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/tasmota/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/tasmota/POWER1:.* state\
stat/tasmota/RESULT:.* { $EVENT =~ m,HSBColor...(\d+)\,(\d+)\,(\d+), ? $2 eq ReadingsVal($NAME,"saturation","unknown") ? undef :{"saturation"=>"$2"} : undef }
attr MQTT2_DVES_0C7A27 room MQTT2_DEVICE
attr MQTT2_DVES_0C7A27 setList off:noArg cmnd/tasmota/POWER1 0\
on:noArg cmnd/tasmota/POWER1 1\
toggle:noArg cmnd/tasmota/POWER1 2\
rgb:colorpicker,RGB cmnd/tasmota/COLOR\
saturation:colorpicker,BRI,0,1,100 cmnd/tasmota/HSBCOLOR2\
pct:colorpicker,BRI,0,5,100 cmnd/tasmota/DIMMER\
Speed:colorpicker,BRI,0,1,20 cmnd/tasmota/SPEED\
Fade:uzsuSelect,ON,OFF cmnd/tasmota/FADE $EVTPART1\
mode:colorpicker,BRI,0,1,4 cmnd/tasmota/SCHEME\
on_test:noArg cmnd/tasmota/Backlog Wakeup 100\
\

attr MQTT2_DVES_0C7A27 setStateList on off toggle
attr MQTT2_DVES_0C7A27 webCmd rgb:saturation:pct:Speed:Fade:mode
attr MQTT2_DVES_0C7A27 webCmdLabel Farbe\
:Sättigung\
:Helligkeit\
:speed\
:fade\
:Modus:

setstate MQTT2_DVES_0C7A27 off
setstate MQTT2_DVES_0C7A27 2020-03-04 10:45:20 Channel_1 50
setstate MQTT2_DVES_0C7A27 2020-03-04 10:45:20 Channel_2 39
setstate MQTT2_DVES_0C7A27 2020-03-04 10:45:20 Channel_3 40
setstate MQTT2_DVES_0C7A27 2020-03-04 10:45:20 Color 806467
setstate MQTT2_DVES_0C7A27 2020-03-04 10:45:20 Dimmer 50
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Fade on
setstate MQTT2_DVES_0C7A27 2020-03-01 21:34:23 FallbackTopic cmnd/DVES_0C7A27_fb/
setstate MQTT2_DVES_0C7A27 2020-03-01 21:34:23 GroupTopic cmnd/tasmotas/
setstate MQTT2_DVES_0C7A27 2020-03-04 10:45:20 HSBColor 354,22,50
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Heap 25
setstate MQTT2_DVES_0C7A27 2020-03-01 21:34:23 Hostname tasmota-6695
setstate MQTT2_DVES_0C7A27 2020-03-01 21:34:23 IPAddress 192.168.188.124
setstate MQTT2_DVES_0C7A27 2020-03-03 16:45:01 LWT Online
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 LedTable on
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 LoadAvg 99
setstate MQTT2_DVES_0C7A27 2020-03-01 21:34:23 Module Generic
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 MqttCount 3
setstate MQTT2_DVES_0C7A27 2020-03-04 10:45:20 POWER1 on
setstate MQTT2_DVES_0C7A27 2020-03-01 21:34:23 RestartReason Power on
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Scheme 0
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Sleep 10
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 SleepMode Dynamic
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Speed 20
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Time 2020-03-05T11:05:51
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Uptime 3T13:31:39
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 UptimeSec 307899
setstate MQTT2_DVES_0C7A27 2020-03-01 21:34:23 Version 8.1.0(tasmota)
setstate MQTT2_DVES_0C7A27 2020-02-26 16:09:37 WakeUpDuration 1
setstate MQTT2_DVES_0C7A27 2020-02-26 16:08:30 Wakeup Started
setstate MQTT2_DVES_0C7A27 2020-03-01 21:34:23 WebServerMode Admin
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Wifi_AP 1
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Wifi_BSSId FC:EC:DA:FD:26:1A
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Wifi_Channel 6
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Wifi_Downtime 0T00:00:09
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Wifi_LinkCount 1
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Wifi_RSSI 58
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Wifi_SSId FBF
setstate MQTT2_DVES_0C7A27 2020-03-05 11:05:52 Wifi_Signal -71
setstate MQTT2_DVES_0C7A27 2020-03-05 11:08:50 pct 40
setstate MQTT2_DVES_0C7A27 2020-03-05 11:08:50 rgb 66484B
setstate MQTT2_DVES_0C7A27 2020-03-05 11:08:18 saturation 29
setstate MQTT2_DVES_0C7A27 2020-03-03 15:23:05 state off
setstate MQTT2_DVES_0C7A27 2020-03-03 20:54:40 subscriptions cmnd/DVES_0C7A27_fb/# cmnd/tasmota/# cmnd/tasmotas/#

Beta-User

Der Zeitstempel sollte auch bei allen (augenommen teilweise: saturation) aktualisiert werden. Ursache für die nicht zu sehenden Updates vermutlich:
attr MQTT2_DVES_0C7A27 event-on-change-reading .*
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

Ja, daran lags, man muss auch schon schauen was genau passiert wenn man einen Wert ändert ::)

Also passt alles für die Rückmeldung bei saturation im Template, oder hast du noch was zu meckern ?

Beta-User

Zitat von: TomLee am 05 März 2020, 11:48:31
Also passt alles für die Rückmeldung bei saturation im Template, oder hast du noch was zu meckern ?
Ich werd's in's template einbauen, allerdings in einer leicht reduzierten Form:
stat/tasmota/RESULT:.* { $EVENT =~ m,HSBColor...(\d+)\,(\d+)\,(\d+), ? $2 eq ReadingsVal($NAME,"saturation","unknown") ? undef :{"saturation"=>$2} : undef }
"meckern" hat einen negativen Beigeschmack  ;D , eigentlich will ich nicht meckern, sondern möglichst "gute" Ergebnisse, tut mir leid, wenn das anscheinend manchmal nicht so positiv rüberkommt, wie es gemeint ist. Ich habe aber schon noch ein Haar in der Suppe, der Punkt geht allerdings eher als Frage/Bitte in Rudi's Richtung:

Wir haben grade immer mehr Fälle, wo wir durch recht komplizierte Abfragen wie die obige versuchen, updates zu unterbinden, wenn es eigentlich nichts neues gibt. "Eleganter" wäre es, wenn wir bei allen Hash-Rückgaben einen generellen (optionalen?) Filter hätte, der verwirft, was nicht aktualisiert wird...

@Rudi: wenn ich die Mechanismen richtig verstanden habe, müßte man dafür schlicht und ergreifend einfach nur in 10_MQTT2_DEVICE.pm#L171 readingsBulkUpdateIfChanged() aufrufen.

Das würde zwar das Verhalten von MQTT2_DEVICE mit JSON grundsätzlich ändern, aber ich bin vom Bauchgefühl her geneigt, genau diese Änderung vorzuschlagen, ohne allerdings darüber allzulange nachgedacht zu haben.
Oder alternativ ein Attribut einzuführen, mit dem man das optional einschaltet (bzw. das alte Verhalten mit "einfachem" readingsBulkUpdate() optional wiederherstellt, was mir besser gefiele, als readingsBulkUpdateIfChanged optional anzuschalten)?

Meinungen? (Müssten wir das irgendwo intensiver diskutieren?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

Zitatstat/tasmota/RESULT:.* { $EVENT =~ m,HSBColor...(\d+)\,(\d+)\,(\d+), ? $2 eq ReadingsVal($NAME,"saturation","unknown") ? undef :{"saturation"=>$2} : undef }

Sehe da nix was reduziert wurde ???

Beta-User

...es fehlen zwei """...

(Jetzt hoffe ich mal, das Rudi meinen letzten Beitrag noch zur Kenntnis nimmt, wenn wieder was geschrieben wurde).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatWir haben grade immer mehr Fälle, wo wir durch recht komplizierte Abfragen wie die obige versuchen, updates zu unterbinden, wenn es eigentlich nichts neues gibt.
Warum eigentlich?
Ich will es wissen, wann zuletzt die Steckdose gemeldet hat, dass es aus ist.
Oder wann sich die Temperatur von 8 auf 9 Grad geaendert hat.

Beta-User

Also: Ich will es auch wissen, wenn sich die Temperatur von 8 auf 9 Grad geändert hat. Nach meinem Verständnis von readingsBulkUpdateIfChanged() würde das auch weiterhin einen Event geben, genauso, wenn die Steckdose meldet, dass sie grade aus- oder eingeschaltet wurde.

Bis zu diesem Punkt also völlige Übereinstimmung, und es war auch nicht gewollt, dass sich in der Beziehung irgendwas ändert.

Neulich habe ich allerdings festgestellt, dass z.B. Tasmota auch ständig wiederholend mitteilt, dass die Steckdose z.B. immer noch eingeschaltet _ist_. Und das will ich eigentlich nicht wissen, jedenfalls nicht um den Preis, dass mir der Einschaltzeitpunkt dabei verloren geht...
(Und ich brauche das auch nicht, um zu wissen, dass das Ding noch online ist, das sollte der LWT-Mechanismus erledigen). (Soweit ich das richtig verstanden habe, ist das auch bei den Shellys mit Original-firmware so, dass ständig "immer noch on/off" vermeldet wird, das ist also kein singuläres Tasmota-Thema sondern vermutlich eine "großflächige JSON-Nebenwirkung").

Es geht also darum, genau diese unnötigen update-Infos (ohne Änderung) zu verwerfen, ohne hinterher wieder mit "event-on-change" wenigstens die überflüssige Event-Auswertung durch notify&Co. ausschalten zu müssen.
(Ich war zugegebenermaßen angenehm überrascht, dass es dafür sogar Funktionalität in fhem.pl gibt und frage mich einfach, warum wir die nicht "an der Quelle" nutzen (und warum ich diesen Punkt bisher übersehen hatte bzw. keiner kam und "gemeckert" hat)...)

Hoffe, das einigermaßen nachvollziehbar erläutert und die Funktion readingsBulkUpdateIfChanged() nicht falsch verstanden zu haben ::) .

Wie gesagt: Ein Kompromiss könnte sein, das generell auszuschalten, und wer dann ohne "IfChanged" haben will könnte das via Attribut umschalten?
Zur Vorgehensweise: Ich würde es erst mal kommentarlos ohne Attribut umstellen. Wenn sich dann jemand (berechtigt) beschwert, ist der betreffende Schalter schnell installiert und du kannst bei den Reparaturmaßnahmen entschuldigend darauf verweisen, dass es einen bösen Buben gibt, der das so wollte? (Ich würde - nachdem ich jetzt etwas Zeit hatte, das auf mich wirken zu lassen - nämlich eine Wette eingehen, dass es zwar Beschwerden gibt, allerdings nur von Leuten, die LWT nicht verstanden haben und schlicht auf den "falschen" Wert schielen... Aber je länger das noch so ist, desto mehr potentielle "Aspiranten" haben wir...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

ZitatNeulich habe ich allerdings festgestellt, dass z.B. Tasmota auch ständig wiederholend mitteilt, dass die Steckdose z.B. immer noch eingeschaltet _ist_. Und das will ich eigentlich nicht wissen, jedenfalls nicht um den Preis, dass mir der Einschaltzeitpunkt dabei verloren geht...
(Und ich brauche das auch nicht, um zu wissen, dass das Ding noch online ist, das sollte der LWT-Mechanismus erledigen). (Soweit ich das richtig verstanden habe, ist das auch bei den Shellys mit Original-firmware so, dass ständig "immer noch on/off" vermeldet wird, das ist also kein singuläres Tasmota-Thema sondern vermutlich eine "großflächige JSON-Nebenwirkung").

Würde gerne folgen können, meinst du die teleperiod-Meldungen, die dann PowerX mit beinhalten.
Die kann man auch ausschalten, aber das weißt du ja ?

13:53:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T13:53:49","Uptime":"1T16:50:58","UptimeSec":147058,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
13:58:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T13:58:49","Uptime":"1T16:55:58","UptimeSec":147358,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:03:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:03:49","Uptime":"1T17:00:58","UptimeSec":147658,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:08:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:08:49","Uptime":"1T17:05:58","UptimeSec":147958,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:13:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:13:49","Uptime":"1T17:10:58","UptimeSec":148258,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:18:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:18:49","Uptime":"1T17:15:58","UptimeSec":148558,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":80,"Signal":-60,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:23:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:23:49","Uptime":"1T17:20:58","UptimeSec":148858,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:28:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:28:49","Uptime":"1T17:25:58","UptimeSec":149158,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:33:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:33:49","Uptime":"1T17:30:58","UptimeSec":149458,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:38:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:38:49","Uptime":"1T17:35:58","UptimeSec":149758,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:43:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:43:49","Uptime":"1T17:40:58","UptimeSec":150058,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:48:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:48:49","Uptime":"1T17:45:58","UptimeSec":150358,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}
14:53:49 MQT: tele/sonoffs20/STATE = {"Time":"2020-03-05T14:53:49","Uptime":"1T17:50:58","UptimeSec":150658,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER1":"off","Wifi":{"AP":2,"SSId":"FBF","BSSId":"BC:05:43:CA:4F:AC","Channel":13,"RSSI":82,"Signal":-59,"LinkCount":1,"Downtime":"0T00:00:06"}}