readingsProxy: state aktualisiert sich nicht

Begonnen von mcp, 08 Mai 2020, 11:59:55

Vorheriges Thema - Nächstes Thema

mcp

Hallo liebe FHEMler :)

vorab: ich beschäftige mich mit FHEM ca. 2 Monate, also quasi ein Frischling.

Ich habe zu meinem Problem einige Posts gefunden die das gleiche Problem beschreiben, aber ohne Lösung. Falls ich was übersehen haben sollte bitte ich um Entschuldigung.

Zum Problem:

das state Reading dieses Devices aktualisiert sich nicht automatisch wenn man schaltet sondern nur via setreading und/oder einem notify:


Internals:
   DEF        Peha_PHC
   DEVICE     Peha_PHC
   FUUID      5eadaf61-f33f-b956-01b6-41f4d1383810fad2
   NAME       PHC_BL_Keller_Buero_Deckenlampe_vorne
   NOTIFYDEV  global,Peha_PHC
   NR         97
   NTFY_ORDER 50-PHC_BL_Keller_Buero_Deckenlampe_vorne
   READING    Keller_Buero_Deckenlampe_vorne
   STATE      off
   TYPE       readingsProxy
   CONTENT:
     Peha_PHC   1
   READINGS:
     2020-05-08 11   lastCmd         off
     2020-05-08 11   state           off
Attributes:
   genericDeviceType light
   homebridgeMapping On=state,cmdOn=on,cmdOff=off,valueOn=on,valueOff=off
   room       23_Homekit,PEHA_Labor
   setFn      {
my ($hash) = @_;

my $NAME = $hash->{NAME};

my $peha_switch = AttrVal($NAME,'pehaSwitch','attr_not_set');

if ($peha_switch eq "attr_not_set") {
$peha_switch = $NAME;
$peha_switch =~ s/_.*?_/_SW_/;
}

my $STATE = ReadingsVal($NAME,'state','error');

if ("$CMD" ne "$STATE") {
if ("$CMD" eq "on") {
fhem("set Peha_PHC $peha_switch ein>0");
#fhem("setreading $NAME lastCmd on");
#fhem("setreading $NAME state on");
} else {
fhem("set Peha_PHC $peha_switch aus<1");
#fhem("setreading $NAME lastCmd off");
#fhem("setreading $NAME state off");
}
}
   }
   setList    on off
   siriName   PHC_BL_Keller_Buero_Deckenlampe_vorne
   userattr   pehaSwitch
   valueFn    {($VALUE == 0)?"off":"on"}
   webCmd     on:off


ist das beabsichtigt oder ein Bug oder habe ich irgendwo einen Fehler? Ich benutze FHEM 6.0 + aktuelle Updates Stand vorgestern.

FHEM stört das nicht weiter jedoch stört sich Homebridge daran da das Device in HB dann nicht aktualisiert wird.

Kleiner Wunsch: $NAME im readingsProxy default verfügbar machen :)

Kleinen Bug gefunden bei list: alles nach einem Doppelpunkt verschwindet, via list:

   valueFn    {($VALUE == 0)?"off"
   webCmd     on


in Wirklichkeit aber:

   valueFn    {($VALUE == 0)?"off":"on"}
   webCmd     on:off



Vielen Dank!
Maintainer: 98_vitoconnect.pm
Raspberry Pi 4B, 4 GB RAM, 32 GB SD Karte
Raspbian Bullseye 32-bit, FHEM up2date

Beta-User

Hmm, irgendwie scheinen grade viele Leute Verständnisprobleme mit readingsProxy zu haben...

So richtig habe ich das noch nicht verstanden, wo eigentlich das Problem liegt und wie man das ggf. nachstellen kann, daher eher auf Verdacht ein paar Anmerkungen.

Was vielfach Probeme zu machen scheint: in manchen Fällen gibt es weniger (interne) Events als die user erwarten; ich vermute, dass da das Problem von Homebridge liegt. Könnte sein, dass man "event-on-update-reading .*" an dem readingsProxy ergänzen muß (ungetestete Vermutung...).

Was $NAME angeht: Hast du schon mal $name verwendet?
Und das Zieldevice ist einfach $DEVICE, das scheinst du ja irgendwie mit der userAttr-Konstruktion rausfinden zu wollen?
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

mcp

Hallo Beta-User,

vielen Dank für die schnelle Rückmeldung.

Zitat von: Beta-User am 08 Mai 2020, 12:25:42
Hmm, irgendwie scheinen grade viele Leute Verständnisprobleme mit readingsProxy zu haben...
:-/ sorry - ich lerne täglich dazu.

Zitat von: Beta-User am 08 Mai 2020, 12:25:42
So richtig habe ich das noch nicht verstanden, wo eigentlich das Problem liegt und wie man das ggf. nachstellen kann, daher eher auf Verdacht ein paar Anmerkungen.
das State nicht aktualisiert wird :)

Zitat von: Beta-User am 08 Mai 2020, 12:25:42
Was vielfach Probeme zu machen scheint: in manchen Fällen gibt es weniger (interne) Events als die user erwarten; ich vermute, dass da das Problem von Homebridge liegt. Könnte sein, dass man "event-on-update-reading .*" an dem readingsProxy ergänzen muß (ungetestete Vermutung...).
aaah, ok - das funktioniert wunderbar, state wird aktualisiert. Ich bin zwar der Meinung dass ich das gestern auch schon probiert habe und es nicht geklappt hat, aber vielleicht komme ich auch durcheinander. Danke!
Hast Du auch noch einen Tip für mich wie ich lastCmd aktualisiert bekomme ohne setreading?

Zitat von: Beta-User am 08 Mai 2020, 12:25:42
Was $NAME angeht: Hast du schon mal $name verwendet?
nein, aber jetzt gerade. Fehlermeldung:


Global symbol "$name" requires explicit package name (did you forget to declare "my $name"?) at (eval 108489) line 2.


Zitat von: Beta-User am 08 Mai 2020, 12:25:42
Und das Zieldevice ist einfach $DEVICE, das scheinst du ja irgendwie mit der userAttr-Konstruktion rausfinden zu wollen?
das ist etwas für ein anderes Konstrukt, könnte eigentlich auch raus - bin derzeit noch viel am ausprobieren wie ich Peha PHC am sinnvollsten an-/einbinden kann.
Maintainer: 98_vitoconnect.pm
Raspberry Pi 4B, 4 GB RAM, 32 GB SD Karte
Raspbian Bullseye 32-bit, FHEM up2date

Beta-User

...das mit dem "Verständnisproblem" war auch nicht als Kritik zu verstehen, sondern eher als "ich bin verwundert, wo kommt das auf einmal in der verstärkten Form her...?"

Hm, also: lastCmd ist offenbar wirklich "hart" nichttriggernd ausgeführt. ABER: der Wert wird aktualisiert, man sieht es nur in FHEMWEB nicht...
Versuch mal einen refresh des Fensters oder frage es via ReadingsVal() ab ;) .

$name&Co sind "schillernd", mal funktioniert das eine, mal das andere, manchmal eben alles nicht. Grade bei den "alten Modulen" ist es aber häufig so, dass man irgendwas übersieht, wenn man plötzlich auf den Gedanken kommt, dass etwas fehlt. Hier wäre ggf. hilfreich zu wissen, wie das PeHa-Gerät eigentlich aussieht und wie da was zu schalten ist. Vermutlich sollte der readingsProxy sich auf ein Reading beziehen, das "Zielreading" aus dem Namen des readingsProxy abzuleiten dürfte jedenfalls nicht der geschickteste Weg sein...
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

mcp

#4
Zitat von: Beta-User am 08 Mai 2020, 13:13:45
...das mit dem "Verständnisproblem" war auch nicht als Kritik zu verstehen, sondern eher als "ich bin verwundert, wo kommt das auf einmal in der verstärkten Form her...?"
ah ok - ja, gute Frage :)

Zitat von: Beta-User am 08 Mai 2020, 13:13:45
Hm, also: lastCmd ist offenbar wirklich "hart" nichttriggernd ausgeführt. ABER: der Wert wird aktualisiert, man sieht es nur in FHEMWEB nicht...
Versuch mal einen refresh des Fensters oder frage es via ReadingsVal() ab ;) .
ja, refresh geht.

Zitat von: Beta-User am 08 Mai 2020, 13:13:45
$name&Co sind "schillernd", mal funktioniert das eine, mal das andere, manchmal eben alles nicht. Grade bei den "alten Modulen" ist es aber häufig so, dass man irgendwas übersieht, wenn man plötzlich auf den Gedanken kommt, dass etwas fehlt. Hier wäre ggf. hilfreich zu wissen, wie das PeHa-Gerät eigentlich aussieht und wie da was zu schalten ist. Vermutlich sollte der readingsProxy sich auf ein Reading beziehen, das "Zielreading" aus dem Namen des readingsProxy abzuleiten dürfte jedenfalls nicht der geschickteste Weg sein...
mehr als https://forum.fhem.de/index.php/topic,71011.0/all.html weiß ich derzeit auch nicht wirklich.

Ja, geschickt ist das nicht, aber wenn ich die Namenskonvention exakt so beibehalte aber doch irgendwie schon :)

Maintainer: 98_vitoconnect.pm
Raspberry Pi 4B, 4 GB RAM, 32 GB SD Karte
Raspbian Bullseye 32-bit, FHEM up2date

Beta-User

Hm, also: Wenn der refresh klappt, mußt du auch nichts via setreading setzen, der Wert müßte dann ja schon passen, oder?

Und ein list habe ich in dem anderen Thread jetzt nicht auf die Schnelle gesehen. Der Name sollte in einer Perl-Funktion innerhalb FHEM "notfalls" mit $hash->{NAME} zu bekommen sein, falls das weiterhilft auf dem Weg, das via Namenskonvention für deinen speziellen Fall aufzubohren?
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

mcp

#6
Zitat von: Beta-User am 08 Mai 2020, 15:20:45
Hm, also: Wenn der refresh klappt, mußt du auch nichts via setreading setzen, der Wert müßte dann ja schon passen, oder?
jep.

Zitat von: Beta-User am 08 Mai 2020, 15:20:45
Und ein list habe ich in dem anderen Thread jetzt nicht auf die Schnelle gesehen. Der Name sollte in einer Perl-Funktion innerhalb FHEM "notfalls" mit $hash->{NAME} zu bekommen sein, falls das weiterhilft auf dem Weg, das via Namenskonvention für deinen speziellen Fall aufzubohren?
ein List siehst Du hier https://forum.fhem.de/index.php/topic,71011.msg1051041.html#msg1051041 und auch hier im Thread im ersten Post - oder welches List meinst Du?

Zu Anfang hatte ich den Schalter als DOIF drin, nur da gibt es keine setExtensions, daher dann via readingsProxy.

Und ja, $NAME habe ich genau so via hash in der setFn Funktion schon drin.

Ich dachte halt nur dass es schön wäre im readingsProxy auch direkt $NAME zur Verfügung zu haben wie in so vielen anderen Modulen :)
Maintainer: 98_vitoconnect.pm
Raspberry Pi 4B, 4 GB RAM, 32 GB SD Karte
Raspbian Bullseye 32-bit, FHEM up2date

Beta-User

Hm, das ist ein list vom dem readingsProxy, nicht vom "Hauptdevice".

Eigentlich ist readingProxy dafür gemacht, das Vereinzeln zu vereinfachen, diese komplexeren Perl-scriptereien sollten damit eigentlich eher vermieden werden. Glaube daher nicht, dass das mit $NAME (oder $name ;) ) zu große Chancen hat, Eingang zu finden. Aber wir werden sehen...
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

mcp

Zitat von: Beta-User am 08 Mai 2020, 17:36:31
Hm, das ist ein list vom dem readingsProxy, nicht vom "Hauptdevice".
ach so :)

hier, aber nicht komplett da das gefühlt 37 Seiten sind mit den ganzen EMDs, AMDs, JRMs and whatnot:


Internals:
   BUSY       0
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AM00E9P0-if00-port0
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AM00E9P0-if00-port0@19200,8,N,2
   EXPECT     
   FD         8
   FUUID      5e8b25dd-f33f-b956-0217-d395ca0fbd9f4026
   ModuleVersion 0.44 - 16.4.2020
   NAME       Peha_PHC
   NR         94
   PARTIAL   
   RAWBUFFER  e009000311242a05080514ff6e
   STATE      opened
   TYPE       PHC
   devioLoglevel 3
   skipBytes 
   skipReason
   OLDREADINGS:
   READINGS:
     2020-05-08 17:24:42   AMD00-o02       Aus verzögert
     2020-05-08 17:24:43   AMD00-o03       Aus verzögert
     2020-05-08 17:24:41   AMD00-o06       Aus verzögert
     2020-05-08 17:24:44   AMD00-o07       FB_Timer_Aus
     2020-05-08 17:35:39   AMD01-o06       Aus verzögert
     2020-05-08 17:11:39   AMD02-o00       Aus
     2020-05-08 16:38:46   AMD03-o04       Aus
     2020-05-08 16:38:46   AMD04-o07       Aus
     2020-05-08 17:21:37   AMD09-o01       Aus verzögert
     2020-05-08 16:38:16   AMD09-o06       Aus
     2020-05-08 17:21:42   AMD09-o07       FB_Timer_Aus
     2020-05-08 16:37:48   DIM00-o00       Aus
     2020-05-08 16:37:48   DIM00o02        0
     2020-05-08 16:37:48   DIM00o03        0
     2020-05-08 16:37:48   DIM00o04        0
     2020-05-08 16:37:48   DIM00o05        0
     2020-05-08 16:37:48   DIM00o06        0
     2020-05-08 16:39:16   EG_Esszimmer_Deckenlampen_8x 0
     2020-05-08 17:21:42   EG_Esszimmer_Esstischlampe 0
     2020-05-08 17:24:42   EMD00-i05       Aus < 1
     2020-05-08 17:24:43   EMD00-i06       Aus < 1
     2020-05-08 16:37:58   JRM06-o00       FB_Heben_Aus
     2020-05-08 17:11:39   Keller_Buero_Deckenlampe_vorne 0
     2020-05-08 17:35:39   LastCommand     AMD01o06 F9 Aus verzögert Time1 1800 data xC9,x08,x07 ack x00,x40 tg 1 OG_Badezimmer_Wandlampen_2x
   Toggle:
     0          c
     1          s
     10         s
     160        s
     161        s
     162        s
     163        s
     164        s
     165        s
     2          s
     224        c
     3          c
     4          s
     5          s
     6          s
     64         s
     65         s
     66         s
     67         s
     68         c
     69         c
     70         c
     71         s
     72         c
     73         s
   helper:
     buffer     
     lastRead   1588952182.01278
Attributes:
   EMDReadings 1
   channelAMD02o00description Keller Büro Deckenlampe vorne
   channelJRM08o07description Zeitmessung frei 3
   module000description Eingangsmodul 24 V LED
   module000type EMD
   module001description Eingangsmodul 24 V LED
   module160description Phasenabschnittdimmer
   module160type DIM
   module161description Phasenabschnittdimmer
   module161type DIM
   module224type CLK
   room       17_Peha
   virtEMD10C01Name PHC_SW_Keller_Buero_Deckenlampe_vorne
   virtEMD10C02Name PHC_SW_EG_Kueche_Rolllade_runter
   virtEMD10C03Name PHC_SW_EG_Kueche_Rolllade_rauf
   virtEMD10C04Name PHC_SW_EG_Kueche_Rolllade_rauf_und_runter
   virtEMD10C05Name PHC_SW_EG_Kueche_Rolllade_runter_Basisprogrammierung
   virtEMD10C06Name PHC_SW_EG_Kueche_Rolllade_rauf_Basisprogrammierung



Wenn es Dir irgendwie weiter hilft kann ich dir das komplett als PM schicken.


Zitat von: Beta-User am 08 Mai 2020, 17:36:31
Eigentlich ist readingsProxy dafür gemacht, das Vereinzeln zu vereinfachen, diese komplexeren Perl-scriptereien sollten damit eigentlich eher vermieden werden. Glaube daher nicht, dass das mit $NAME (oder $name ;) ) zu große Chancen hat, Eingang zu finden. Aber wir werden sehen...
ja, wenn Du eine Idee hast wie ich den Schalter mit dem Code vereinfachen kann - gerne!
Maintainer: 98_vitoconnect.pm
Raspberry Pi 4B, 4 GB RAM, 32 GB SD Karte
Raspbian Bullseye 32-bit, FHEM up2date

Beta-User

OK, das ist sehr "speziell"...

Vielleicht hilft es dir und mir, wenn du die "Kette" für das sub-Device mal darstellst, das du in dem readingsProxy drin hast. Also: Wie sieht der eigentliche Sende-Befehl aus, wie sehen die zugehörigen Events dann aus bzw. wie ändern sich die Readings am Hauptdevice, so was eben...
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

fireball

Hi,

ich glaube ich habe eine ähnliches Problem, welches ich aktuell nicht verstehe.

Ich habe einen RedingsProxy auf ein Reading (Temperaturwert der WärmePumpe, die ich mit Luxtronik auslese)

Internals:
   DEF        LAD7:hotWaterTemperatureTarget
   DEVICE     LAD7
   FUUID      5e56d062-f33f-0804-59d9-46cf71c552126ba5
   NAME       RP_Warmwasser
   NOTIFYDEV  global,LAD7
   NR         514
   NTFY_ORDER 50-RP_Warmwasser
   READING    hotWaterTemperatureTarget
   STATE      48.0
   TYPE       readingsProxy
   eventCount 7
   CONTENT:
     LAD7       1
   READINGS:
     2023-07-13 21:50:05   lastCmd         kälter
     2023-07-15 17:09:42   state           48.0
Attributes:
   alias      RP_Warmwasser
   icon       temp_control
   room       BAD,HWR
   setFn      {my $Wert=ReadingsVal("LAD7","hotWaterTemperatureTarget",0);
  if($CMD eq "wärmer") {
   $Wert = $Wert+0.5;
  }
  if($CMD  eq "kälter") {
   $Wert = $Wert-0.5;
  }
  fhem("set LAD7 hotWaterTemperatureTarget $Wert");
}
   setList    kälter wärmer
   verbose    5
   webCmd     kälter:wärmer

Dieser Proxy zeigt mir im State die eingestelle Temperatur an und ich kann über wärmer und kälter in 0,5Grad schritten diese Temperatur erhöhen.

Mein Problem ist, dass der Wert hotWaterTemperatureTarget sich nicht ändert.

Ich hatte erst das event-on-change-reading in der LAD7 unter verdacht, aber als ich das wieder rausgenommen habe, passiert auch nix.
Dann habe ich dem readingsProxy event-min-interval vergeben, weil ich es so verstanden habe, dass er dadurch den Wert immer wieder erneuert (Wert:10 war die Einstellung), aber auch das ist nicht der Fall.

Also meine konkrete Frage wäre, wie bekomme ich es hin, dass ich in FHEMWEB sofort die Änderung des Wertes sichtbar bekomme?
Früher hatte ich noch ein extra "setreading LAD7 hotWaterTemperatureTarget $Wert" mit in meiner setFn, viell lags auch daran, dass es mal ging, aber konkret bekomme ich es nicht mehr hin.

Kleiner Anstoß wäre sehr hilfreich.

VG
René