[22.01.22] hue switch schaltet von selber

[the ratman]

hiho,

seit heute scheint mein hue switch

Code Auswählen Erweitern

defmod sw_frei HUEDevice sensor 6 1 IODev=huebridge
attr sw_frei IODev huebridge
attr sw_frei alias taster tatortreiniger
attr sw_frei group schalter
attr sw_frei icon 183-switch
attr sw_frei model RWL021
attr sw_frei room hue
attr sw_frei webCmd statusRequestzu spinnen. mindestens 1 mal alle 15 minuten sendet er.
scheinbar sind das die normalen stautsupdates, die aber mein doif, das auf den switch reagiert als neu gesendeten wert interpretiert (ob ich den state "normal" oder per stteevent abfrage scheint egal zu sein).
ausschnitt aus dem doif:

Code Auswählen Erweitern

([sw_frei:"^state: 1002$"] and [?doif_tag_nacht:zustand] eq "tag" and [?kuechentuer_lichtschranke:state] eq "open" ) ## KÜCHE offen

( set tatortreiniger nextCleaningMode turbo, set tatortreiniger nextCleaningZone 2bf8bbed-f37b-43fb-9671-722ca2582a07, set tatortreiniger startCleaning zone )
( say reinigung der küche beginnt. ist der boden frei? )
DOELSEIF ## 02
([sw_frei:"^state: 1002$"] and [?doif_tag_nacht:zustand] eq "tag" and [?kuechentuer_lichtschranke:state] eq "closed" ) ## KÜCHE geschlossen

( say soll der sauger durch die glastüre fahren oder will sie jemand öffnen? )

da es derzeit ja so einige hue-updates gibt, frag ich mich: spinnt mein schalter, oder liegts an den updates?

alles an fhem ist tagesaktuell.
normales drücken quittiert der switch auch normal und ist auch immer erreichbar lt. fhem.
fehler/warnings gibt's im log keine, auch wenn ich verbose mal höher drehe.
umgestellt hab ich an dem konstrukt (bis auf statevent im doif zum heutigen testen) seit monaten nichts mehr.

bitte um hilfe! derzeit hilft es nur, das doif zu deaktivieren, will ich nicht die batterie aus dem switch nehmen.

[justme1968]

ich brauche ein log mit verbose 4 der daten die zu dem zeitpunkt von der bridge kommen und mit verbose 5 vom switch device.

[Benni]

[22.01.22] hue switch schaltet von selber

OT: Das ist dann übrigens erst übermorgen!

gb#

[the ratman]

ich bin meiner zeit immer schon voraus gewesen *g*

und was die uhrzeit angeht - eben hat der schalter readings geschrieben - aber auch mit der falschen uhrzeit:

Code Auswählen Erweitern

state 1002 2022-01-20 11:06:21es ist 14:41 - der rest von fhem ist ebenfalls dieser meinung ...
dazu passend im log:

Code Auswählen Erweitern

2022.01.20 14:41:23 4:  parse status message for sw_frei
2022.01.20 14:41:23 4:  sw_frei: use offsetUTC 3600 from bridge

vielleicht ist ja da schon das problem, weil momentan will der schalter sich nicht falsch verhalten ...
wenn ers den mal tut, bring ich 2 logs nach ...


und falls man vielleicht da schon was rauslesen kann:

Code Auswählen Erweitern

2022.01.20 14:46:14 4:  using HttpUtils_NonblockingGet: GET lights/11
2022.01.20 14:46:14 4:  huebridge: dispatch
2022.01.20 14:46:23 4:  using HttpUtils_NonblockingGet: GET
2022.01.20 14:46:23 4:  huebridge: dispatch
2022.01.20 14:46:23 4:  huebridge: parse status message
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S69
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S7
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S42
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S70
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S41
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S54
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S62
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S53
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S40
2022.01.20 14:46:23 4:  huebridge: message for unknown sensor received: huebridge-S63
2022.01.20 14:46:23 4:  parse status message for sw_frei
2022.01.20 14:46:23 4:  sw_frei: use offsetUTC 3600 from bridge
2022.01.20 14:46:43 4:  huebridge: dispatch
2022.01.20 14:46:43 4:  name: EventStream: connected
2022.01.20 14:46:43 4:  huebridge: received: $VAR1 = [
          {
            'data' => [
                        {
                          'owner' => {
                                       'rtype' => 'device',
                                       'rid' => '2f2c30bb-ad63-4a96-9ff6-271a25028287'
                                     },
                          'id_v1' => '/sensors/66',
                          'temperature' => {
                                             'temperature' => '18.6299991607666',
                                             'temperature_valid' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
                                           },
                          'id' => '1856cf24-4350-4557-9055-d0a6c7bd84c0',
                          'type' => 'temperature'
                        }
                      ],
            'creationtime' => '2022-01-20T13:46:43Z',
            'type' => 'update',
            'id' => '6e8debe5-1d5d-4b88-8412-f7761c2e8707'
          }
        ];

2022.01.20 14:46:43 4:  huebridge: got update event
2022.01.20 14:46:43 4:  huebridge: created from event: $VAR1 = {
          'v2_service' => '1856cf24-4350-4557-9055-d0a6c7bd84c0',
          'state' => {
                       'temperature' => 1862,
                       'lastupdated' => '2022-01-20T13:46:43'
                     },
          'v2_id' => '2f2c30bb-ad63-4a96-9ff6-271a25028287'
        };

2022.01.20 14:46:52 4:  huebridge: dispatch
2022.01.20 14:46:52 4:  name: EventStream: connected
2022.01.20 14:46:52 4:  huebridge: received: $VAR1 = [
          {
            'id' => 'bf51e871-2de0-49d5-8a83-99d87a21bfdd',
            'type' => 'update',
            'creationtime' => '2022-01-20T13:46:52Z',
            'data' => [
                        {
                          'owner' => {
                                       'rid' => '417a5dcd-b5de-4e45-a23a-a323e98d54cf',
                                       'rtype' => 'device'
                                     },
                          'id_v1' => '/sensors/10',
                          'light' => {
                                       'light_level' => 8874,
                                       'light_level_valid' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
                                     },
                          'type' => 'light_level',
                          'id' => '57b1defc-9c14-4ac4-bf31-05e7d859efbc'
                        }
                      ]
          }
        ];

2022.01.20 14:46:52 4:  huebridge: got update event
2022.01.20 14:46:52 4:  huebridge: created from event: $VAR1 = {
          'v2_id' => '417a5dcd-b5de-4e45-a23a-a323e98d54cf',
          'state' => {
                       'lightlevel' => 8874,
                       'lastupdated' => '2022-01-20T13:46:52'
                     },
          'v2_service' => '57b1defc-9c14-4ac4-bf31-05e7d859efbc'
        };

2022.01.20 14:47:23 4:  using HttpUtils_NonblockingGet: GET
2022.01.20 14:47:23 4:  huebridge: dispatch
2022.01.20 14:47:23 4:  huebridge: parse status message
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S53
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S40
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S63
2022.01.20 14:47:23 4:  parse status message for sw_frei
2022.01.20 14:47:23 4:  sw_frei: use offsetUTC 3600 from bridge
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S7
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S42
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S69
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S70
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S54
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S41
2022.01.20 14:47:23 4:  huebridge: message for unknown sensor received: huebridge-S62

[the ratman]

hab jetzt mal einen statusrequest auf den schalter gemacht - hier das log:

Code Auswählen Erweitern

2022.01.20 14:53:29 1:  logfile wurde gelöscht
2022.01.20 14:53:54 4:  huebridge: dispatch
2022.01.20 14:53:54 4:  name: EventStream: connected
2022.01.20 14:53:54 4:  huebridge: received: $VAR1 = [
          {
            'type' => 'update',
            'id' => 'db5b2199-790f-4002-9a5c-6b89d6e3d763',
            'data' => [
                        {
                          'owner' => {
                                       'rtype' => 'device',
                                       'rid' => '2f2c30bb-ad63-4a96-9ff6-271a25028287'
                                     },
                          'id_v1' => '/sensors/65',
                          'light' => {
                                       'light_level_valid' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
                                       'light_level' => 7499
                                     },
                          'type' => 'light_level',
                          'id' => '9b6f5538-fd5d-4167-9528-0745d19383e1'
                        }
                      ],
            'creationtime' => '2022-01-20T13:53:54Z'
          }
        ];

2022.01.20 14:53:54 4:  huebridge: got update event
2022.01.20 14:53:54 4:  huebridge: created from event: $VAR1 = {
          'v2_service' => '9b6f5538-fd5d-4167-9528-0745d19383e1',
          'state' => {
                       'lightlevel' => 7499,
                       'lastupdated' => '2022-01-20T13:53:54'
                     },
          'v2_id' => '2f2c30bb-ad63-4a96-9ff6-271a25028287'
        };

2022.01.20 14:53:55 4:  using HttpUtils_NonblockingGet: GET sensors/6
2022.01.20 14:53:56 4:  huebridge: dispatch
2022.01.20 14:53:56 4:  parse status message for sw_frei
2022.01.20 14:53:56 4:  sw_frei: use offsetUTC 3600 from bridge
2022.01.20 14:53:56 4:  using HttpUtils_NonblockingGet: PUT lights/11/state
2022.01.20 14:53:56 4:  huebridge: dispatch
2022.01.20 14:53:57 4:  using HttpUtils_NonblockingGet: GET lights/11
2022.01.20 14:53:57 4:  huebridge: dispatch
2022.01.20 14:54:08 4:  huebridge: dispatch
2022.01.20 14:54:08 4:  name: EventStream: connected
2022.01.20 14:54:08 4:  huebridge: received: $VAR1 = [
          {
            'data' => [
                        {
                          'owner' => {
                                       'rtype' => 'device',
                                       'rid' => '836f04c7-8ba2-46ef-999a-93f738e1f2c5'
                                     },
                          'id_v1' => '/sensors/6',
                          'id' => 'e1243737-4d6a-4ecc-b3d7-806786e9eef1',
                          'type' => 'device_power',
                          'power_state' => {
                                             'battery_level' => 20,
                                             'battery_state' => 'normal'
                                           }
                        }
                      ],
            'creationtime' => '2022-01-20T13:54:08Z',
            'type' => 'update',
            'id' => '21966e57-5822-408a-8cae-235eb7f2d114'
          }
        ];

2022.01.20 14:54:08 4:  huebridge: got update event
2022.01.20 14:54:08 4:  huebridge: created from event: $VAR1 = {
          'v2_service' => 'e1243737-4d6a-4ecc-b3d7-806786e9eef1',
          'state' => {
                       'lastupdated' => '2022-01-20T13:54:08'
                     },
          'v2_id' => '836f04c7-8ba2-46ef-999a-93f738e1f2c5'
        };

2022.01.20 14:54:08 4:  parse status message for sw_frei
2022.01.20 14:54:08 4:  sw_frei: use offsetUTC 3600 from bridge
2022.01.20 14:54:08 4:  sw_frei: lastupdated: 2022-01-20 13:54:08, hash->{lastupdated}:  2022-01-20 10:06:21, lastupdated_local: 2022-01-20 14:54:08, offsetUTC: 3600
und wieder haben die readings ein update bekommen, wieder mit der falschen uhrzeit und das doif hat getriggert:

Code Auswählen Erweitern

IODev
huebridge 2022-01-20 09:28:21
battery 20 2022-01-20 11:06:21
batteryPercent 20 2022-01-20 11:06:21
reachable 1 2022-01-20 11:06:21
state 1002 2022-01-20 11:06:21die uhrzeit fürs i/o-dev ist übrigens jene, zu der ich heute das update gefahren hab.
und auch noch aufgefallen: er nimmt immer "1002", egal, was vorher gedrückt wurde.

nachtrag: alle anderen hue-geräte (auch ein weiterer schalter dieser art) zeigen die richtige uhrzeit.
ich gehe also mal von aus, dass mein schalter was hat.
wie prüf ich das am dümmsten bei hue? hatte mit dem zeug noch keine solchen probleme.

[justme1968]

ein update über statusRequest hat nichts mit den automatisch erzeugten events der bridge zu tun.

ich glaube aber ich habe das problem gefunden. schau mal hier: https://forum.fhem.de/index.php/topic,122075.msg1202181.html#msg1202181

[the ratman]

ah, gut
wenn ich das richtig interpretiere, ist das also in arbeit?
weil ich bin auf der tagesaktuellen version, kann also nix mehr updaten.

und wegen des statusrequest: auch bei dieser abfrage erwarte ich mir nicht, dass meine geräte anlaufen *g*.

[the ratman]

heutiges update gemacht ... und falls es eventuell interessant sein könnte:

Code Auswählen Erweitern

2022.01.21 08:39:00 0:  Server started with 349 defined entities (fhem.pl:25521/2022-01-20 perl:5.028001 os:linux user:fhem pid:22119)
2022.01.21 08:39:01 1:  PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/30_HUEBridge.pm line 2219.
2022.01.21 08:39:01 1:  stacktrace:
2022.01.21 08:39:01 1:      main::__ANON__                      called by ./FHEM/30_HUEBridge.pm (2219)
2022.01.21 08:39:01 1:      main::HUEBridge_dispatch            called by FHEM/HttpUtils.pm (647)
2022.01.21 08:39:01 1:      main::__ANON__                      called by fhem.pl (771)

bisher kam die letzten tage immer nach dem update ein warning pro gerät - ist diesmal mit nur einem warning also weniger.

[justme1968]

fehlen da noch irgendwelche zeilen oder ist das komplett ?

[the ratman]

das warning nach dem update? nö, ist komplett und kommt nur einmalig.
ist aber auch nur globales verbose 1.

aja, ein neues hab ich noch:
die uhrzeiten von batteriestate sind nun richtig.
die restlichen zeiten immer noch falsch.

Code Auswählen Erweitern

IODev huebridge 2022-01-21 08:38:44
battery 22 2022-01-20 11:06:21
batteryPercent 22 2022-01-20 11:06:21
batteryState normal 2022-01-21 10:57:32
reachable 1 2022-01-20 11:06:21
state 1002 2022-01-20 11:06:21

[justme1968]

bitte probier auch mal die version von hier: https://forum.fhem.de/index.php/topic,122075.msg1202401.html#msg1202401

[the ratman]

wird gemacht:

o) kein warning mehr im log nach dem update+restart.
o) nach dem drücken div. tasten stimmts datum aller readings wieder.

NACHTRAG (ca. 20 min danach)
o) alles beim alten - datum falsch (bleibt wieder hinten nach) das einzig aktuelle reading datum ist jetzt "batterystate"
o) wieder ein sinnloses senden von "1002" am state und somit auslösen meines doif's.

[justme1968]

log mit verbose 5 und event monitor wenn das passiert zeigen

[the ratman]

bitte, dein log verbose 5 beim schalter:

Code Auswählen Erweitern

2022.01.21 18:57:44 1:  logfile wurde gelöscht
2022.01.21 18:58:27 4:  parse status message for sw_frei
2022.01.21 18:58:27 4:  sw_frei: use offsetUTC 3600 from bridge
2022.01.21 18:58:48 4:  parse status message for sw_frei
2022.01.21 18:58:48 4:  sw_frei: use offsetUTC 3600 from bridge
2022.01.21 18:58:48 4:  sw_frei: lastupdated: 2022-01-21_17:58:48, hash->{lastupdated}:  2022-01-21_14:56:24, lastupdated_local: 2022-01-21 18:58:48, offsetUTC: 3600
2022.01.21 18:59:27 4:  parse status message for sw_frei
2022.01.21 18:59:27 4:  sw_frei: use offsetUTC 3600 from bridge
2022.01.21 18:59:27 4:  sw_frei: lastupdated: 2022-01-21_14:56:24, hash->{lastupdated}:  2022-01-21_17:58:48, lastupdated_local: 2022-01-21 15:56:24, offsetUTC: 3600


und es gibt auch wieder die üblichen falschen zeiten.
alle readings bis auf iodev sind bei dem vorgang aktualisiert worden

Code Auswählen Erweitern

IODev huebridge 2022-01-21 15:51:25
battery 13 2022-01-21 15:56:24
batteryPercent 13 2022-01-21 15:56:24
batteryState normal 2022-01-21 18:58:48
reachable 1 2022-01-21 15:56:24
state 1002 2022-01-21 15:56:24

[justme1968]

das ist nicht die aktuelle version sondern immer noch die von gestern. in der aktuellen gibt es keine log zeilen mit lastupdated mehr.

[the ratman]

ich hab nix zum updaten in fhem und dein link führte zu einem beitrag von dir, wo nur stand, dass die neueste version schon eingecheckt wurde.

da müsstest du mir also schon die neue version zukommen lassen ...

[Jamo]

Hallo ratman,
die aktuelle version, die auch bei mir funktioniert, kannst Du Dir mit folgenden kommandos (in der fhem commandozeile eingeben) wie folgt aus dem svn laden:
{ Svn_GetFile('FHEM/31_HUEDevice.pm', 'FHEM/31_HUEDevice.pm') }
{ Svn_GetFile('FHEM/30_HUEBridge.pm', 'FHEM/30_HUEBridge.pm') }

Danach ein fhem re-start machen.

[daedalus0815]

...ich habe deconz im Einsatz und mit dem erwähnten Update konnten meine Philips Switch model RWL021 nicht mehr schalten,
da kam absolut nichts mehr im EventMonitor an von meinen HUEs*....   

....und
{ Svn_GetFile('FHEM/31_HUEDevice.pm', 'FHEM/31_HUEDevice.pm') }
{ Svn_GetFile('FHEM/30_HUEBridge.pm', 'FHEM/30_HUEBridge.pm') }
...änderte daran leider auch nichts.

Alte HUE-Dateien (Bridge/device) aus Backup eingespielt...und alles läuft wie immer


VG

[the ratman]

thx für die info @Jamo
hab's mal upgedated - schauen ma mal *g*

schaut aber schon mal gut aus die ersten minuten - eine erste (automatische) aktualisierung der readings lässt den status in ruhe.
gab auch nach dem update keine warnings mehr. morgen mal wieder das doif anwerfen und gucken, was so passiert ...

[justme1968]

@daedalus0815: deine meldung ist leider nicht sehr hilfreich. was sagst das log? was sagt ein list vom device? was sagt der event monitor?

was bedeutet 'nicht mehr schalten' genau?

[the ratman]

noch ne dumme frage: sind die 2 hue pm's, die heute morgen im update liegen aktueller oder älter als die gestern händisch installierten?

sprich: einfach drüber updaten, oder mal vom update raus nehmen?

[Jamo]

Der Befehl holt die Dateien aus dem svn, e.g wenn das Update noch nicht zur Verfügung steht, oder wenn man nur mal einzelne Dateien updaten will.
Ab heute morgen 7:45 gibts ja jetzt das neue update, deswegen kannst Du jetzt einfach ein update machen, danach ein fhem restart.

[the ratman]

dank dir

war nur etwas verwirrt, weil ich zwar genau das dachte, aber meiner logik nach ja dann kein update kommen sollte, da ja die versionen gleich sind - aber gut, nicht das erste mal, dass ich falsch gedacht hab *lach*

[Jamo]

Das Update wird dann trotzdem noch am nächsten morgen angezeigt, wahrscheinlich weil der lokale Timestamp dann noch vom Vortsg ist.
Läufts damit jetzt bei Dir?

[daedalus0815]

Hallo justme1968,

deine meldung ist leider nicht sehr hilfreich. was sagst das log? was sagt ein list vom device? was sagt der event monitor?

Event Monitor ist einfach nur leer, kein HUE-Event weit und breit, obwohl ich mehrere HUE-Funk-Switche betätigt habe, alle funktionslos.....
Funk-Schalter sind also ohne Funktion .....Nix, nothing und nada.....LOG ohne HUE-Einträge   


was bedeutet 'nicht mehr schalten' genau?

Via Web-Oberfäche sind die ZigBee noch schaltbar => Senden funktioniert
Alle HUE-Funkschalter sind "tot" => kein FHEM-Empfang / kein LOG-Eintrag, kein Event Manager - Eintrag
-------------------------------------------------------------

List vom device ist wohl eher unnötig, da meine alte HUE-Bridge/Device-File-Kombi ja auch absolut fehlerfrei funktioniert ....oder ?

P..S:
Als ich noch auf meiner Fehlersuche war, habe ich einen HUE-Funker auch wieder ganz neu angelernt ....war natürlich zwecklos.

[the ratman]

thx für die info @Jamo
ist halt für nen noob wie mich immer etwas verwirrend.

btw - wenn ich schon schreibe: bei mir scheint wieder alles zu rennen, wie es soll.
somit also von meiner seite vielen thx an die informanten und auch an unseren justme1968, weil ers ja doch immer zum laufen bringt, wenn was nicht passt *g*

[daedalus0815]

Gerade Update gemacht.....läuft ! ....alle HUE-Fernbedienungen schalten wie gewohnt 

Toller Job & Schönes Wochenende