[jetzt im svn] [CUL_HM +] patches November 2021

Begonnen von Beta-User, 03 November 2021, 10:55:55

Vorheriges Thema - Nächstes Thema

FFHEM

Hallo Beta-User, Martin,
ich kann mir gut vorstellen, dass Ihr viel "um die Ohren" habt, nur zur Info und nur für den Fall, dass es in Vergessenheit geraten/nicht bekannt/noch nicht erkannt ist:

Es gibt noch das Problem, das ich mit einem HM-Regensensor mit dem Attribut
param      offAtPon,onAtRain
habe. Bei neueren 10_CUL_HM-Versionen (ab ca. August 2021) schaltet die automatische Sensorheizung nicht mehr:

https://forum.fhem.de/index.php/topic,122425.msg1170042.html#msg1170042

Das funktioniert auch mit dem neuesten Patch (noch) nicht.
Gruß,
Friedhelm
Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

Beta-User

#31
Sorry, hatte ich überhaupt nicht auf dem Radar...

noansi hat ja dankenswerter Weise schon hier darauf hingewiesen, wie man (nicht nur) dieses Problem lösen kann. Für die übrigen Fälle scheinen "wir" nach und nach schon Lösungen eingebaut zu haben, der HM-SEN-RD-O scheint die letzte "params"-Sonderlocke gewesen zu sein, die noch gefehlt hat.

Das Modul lädt, und ich hoffe auch, dass ein einfaches Setzen der helper-Einträge ausreichend ist, aber wie üblich kann ich für nichts garantieren ::) ...

(...eigentlich wollte ich ja nur das stateFormat-Problem lösen, und es dann irgendwann auch gut sein lassen, aber weil du so nett gefragt hast... :) )
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

FFHEM

#32
Habe den Patch soeben eingespielt, restliche HM-Module sind alle up-to-date, Regensensor mit Regen beträufelt -> Sensor meldet Regen, aber Heizung ist nicht an!
Mit dieser 10_CUL_HM.pm-Version vom Mai 2021 funktioniert es:
# $Id: 10_CUL_HM.pm 24449 2021-05-16 09:03:48Z martinp876 $

EDIT: Ich habe das Attribut jetzt nicht manuell noch einmal beschrieben, wie ich es sonst zur Reparatur mache, sondern nur den Patch eingespielt,  shutdown restart, Regen simuliert.

Die Heizung:
Internals:
   DEF        67B24202
   FUUID      5ccb033e-f33f-26cd-d907-ac7db584698d01cd
   NAME       Regensensor_Heizung
   NR         1155
   NTFY_ORDER 48-Regensensor_Heizung
   STATE      off
   TYPE       CUL_HM
   chanNo     02
   device     Regensensor
   disableNotifyFn 1
   READINGS:
     2021-11-18 11:22:08   CommandAccepted yes
     2021-11-17 09:35:37   cfgState        ok
     2021-11-18 12:19:40   commState       CMDs_done
     2021-11-18 11:22:08   recentStateType ack
     2021-11-18 11:22:08   state           off
     2021-11-18 11:22:08   timedOn         off
     2021-11-18 11:22:08   trigLast        fhem:02
   helper:
     peerFriend
     peerOpt    -:sensRain
     regLst     
     cmds:
       TmplKey    :no:1637234249.98024
       TmplTs     1637234249.98024
       cmdKey     1:0:0::Regensensor:00A7:02:
       cmdLst:
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         getConfig  noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         off        noArg
         on         noArg
         on-for-timer -sec-
         on-till    -time-
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         toggle     noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
       lst:
         condition  dry,off,on,rain
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     peerIDsH:
     role:
       chn        1
     tmpl:
Attributes:
   alias      Regensensor_Heizung
   group      Wetter
   model      HM-SEN-RD-O
   param      offAtPon,onAtRain
   room       Wetterstation

Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

Beta-User

#33
Sorry, blöder Typo. Jetzt werden auch beim FHEM-Start die helper-Einträge erzeugt...
(Die alte Version zu vergleichen bringt relativ wenig: wie geschrieben hatte noansi ja bereits erläutert, an was es hängt, und an dem Punkt der Attribut-Validierung wird es m.E. kein zurück geben).
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

FFHEM

Sehr gut, Beta-User!
Die Heizung geht jetzt wieder automatisch an und aus, klasse!!!!  ;D ;D ;D
Gruß,
Friedhelm

Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

Beta-User

 :) Danke für die Rückmeldung,

dann werde ich halt dann doch bei Gelegenheit nochmal ein diff in den ersten Post hängen müssen, oder ein "November II" anfangen (?)  ::) ...

@frank: Hast du zufällig schon eine Rückmeldung zu den anderen Themen?
(die übrigen Punkt aus der offenen-Punkte-Liste hatte ich zum Teil mehrfach kurz angeschaut, aber teils war unklar, ob es schon länger gelöst ist (A112), oder ich hatte Verständnisschwierigkeiten zu erfassen, was da überhaupt Sache ist - die Funk-Protokoll-Analyse ist nach wie vor nicht "meins"... Falls da support gewünscht ist, schaue ich es mir an, bräuchte dann aber jemanden, der mir das so erklärt, dass ich folgen kann ;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

jayjay

Wie in https://forum.fhem.de/index.php/topic,124276.0.html diskutiert hatte ich mit der offiziellen CUL_HM Version Probleme beim direkten Pairing von zwei Homematic Geräten, speziell beim Pairing eines 6-fach Tasters HM-PB-6-WM55 an einen Dimmer HM-LC-Dim1TPBU-FM. Der Taster fing beim Drücken der Anlerntaste direkt an gelb zu blinken, anstatt grün zu blinken und auf das Drücken der Taste die angelernt werden soll zu warten. Der direkte Übergang zum gelben Blinken ist das Verhalten beim Anlernen and eine Zentrale im Pairing Modus. Das Verhalten hat sich auch bei Autocreate disabled nicht geändert. Nur wenn ich das Gerät in die ignoreTypes Liste aufnahm hat sich der Taster richtig verhalten und konnte mit dem Aktor direkt gepairt werden.
Mit dem hier diskutiert Update von CUL_HM hat es dann Bestens funktioniert, ohne ignoreType Eintrag.

Ich finde es auch gut, dass neue Geräte z.B. vom Nachbarn aber auch eigene nicht automatisch angelegt werden.

Danke an alle Beitragenden!
FHEM in virtueller Maschine (Ubuntu) auf Intel Serverboard
HM-TC-IT-WM-W-EU, HM-CC-RT-DN, Vitodens 200 Gastherme Anbindung über vcontrol ( leider nur lesend) und Eigenbau Interface als Emulation eines abgesetzten Raumthermostaten (Soll-Temperatur Steuerung)

Timmäää

Martin hat ein Update eingecheckt.. Ich bin gespannt...

Beta-User

Hallo zusammen,

soweit ich das beurteilen kann, ist jetzt der "gesammelte Stand" ins svn übernommen.

Nochmal ein fettes DANKE an alle für's mit testen und überlegen!

Grüße, Beta-User
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

Timmäää

Ohne dich Beta-User wäre das nichts geworden. Auch wenn es tester und maintainer braucht, du hast es getrieben!

Fettes Danke!

Violinux

Auch ich bin überrascht, wie gut CUL_HM nun geht. Seit gestern V-25272
gegen 14 Uhr aus SVN geladen, bis dato keine Probleme. Prima !    :)

Ellert

#41
Seit dem Update erhalte ich ohne erkennbaren Zusammenhang folgengende Warnungen im Abstand von 1-3 Stunden

2021.12.01 17:24:11.849 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_CUL.pm line 939, <GEN8> line 102.
2021.12.01 17:24:11.857 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_HMUARTLGW.pm line 1456, <GEN8> line 102.


mit folgenden Versionen
10_CUL_HM.pm    25272 2021-11-28 12:34:00Z martinp876
98_HMinfo.pm    25159 2021-10-30 17:37:57Z martinp876
00_HMUARTLGW.pm 25203 2021-11-08 09:18:29Z mgernoth


configCheck liefert keine Hinweise.

Hier das Stacktrace zu den Warnungen:
2021.12.02 00:48:40.477 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_CUL.pm line 939.
2021.12.02 00:48:40.479 1: stacktrace:
2021.12.02 00:48:40.480 1:     main::__ANON__                      called by ./FHEM/00_CUL.pm (939)
2021.12.02 00:48:40.481 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (840)
2021.12.02 00:48:40.481 1:     main::CUL_Read                      called by fhem.pl (3895)
2021.12.02 00:48:40.482 1:     main::CallFn                        called by fhem.pl (773)
2021.12.02 00:48:40.489 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_HMUARTLGW.pm line 1456.
2021.12.02 00:48:40.490 1: stacktrace:
2021.12.02 00:48:40.491 1:     main::__ANON__                      called by ./FHEM/00_HMUARTLGW.pm (1456)
2021.12.02 00:48:40.492 1:     main::HMUARTLGW_Parse               called by ./FHEM/00_HMUARTLGW.pm (1574)
2021.12.02 00:48:40.493 1:     main::HMUARTLGW_Read                called by fhem.pl (3895)
2021.12.02 00:48:40.493 1:     main::CallFn                        called by fhem.pl (773)


Beeinträchtigungen sind mir nicht aufgefallen.

Beta-User

Klingt für mich nach Devices ohne zugewiesenes IO (das gab es vorher nicht), also ignore oder dummy.

Kannst du mal folgende defined?-Ergänzung in CUL (ab 937) testen:
if($flgh & 0x20 &&       #noansi: see HMUARTLGW, not to collide with it
           defined $modules{CUL_HM}{defptr}{$src}->{IODev} &&
           $modules{CUL_HM}{defptr}{$src}->{IODev}->{TYPE} =~
                        m/^(?:TSCUL|HMUARTLGW)$/s);
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

Ellert

Ja, ignored und dummy Attribute habe ich bei ein paar Geräten gesetzt, ich teste jetzt mal und melde mich.

Ellert

Die Warnungen bleiben:

2021.12.02 12:12:08.448 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_CUL.pm line 941.
2021.12.02 12:12:08.464 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_HMUARTLGW.pm line 1456.

Zeile 941:                         m/^(?:TSCUL|HMUARTLGW)$/s);