[CUL_HM] patches Oktober 2021 - die Zweite

Begonnen von Beta-User, 15 Oktober 2021, 23:56:29

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,
hallo Martin,

nachdem die großen Baustellen bei CUL_HM vorerst weitgehend abgeräumt sind, aber noch die eine oder andere Kleinigkeit (vor allem dank der unermüdlichen Testerei von frank!) zutage getreten ist, gibt es hier mal wieder einen neuen Thread, in dem wieder die jeweils aktuellsten Stände zu finden sein sollen.

Das ganze ist [WIP], also work in progress und kann daher noch Fehler enthalten, und soll wie das letzte Mal ein Angebot für Martin sein, vorab möglichst getesteten Code dann wieder ins svn einchecken zu können - ergo wäre es wieder super, wenn sich ein paar "Mutige" finden würden, die das vorab testen würden.

Wer testen will: Im Moment sind alle drei Bereiche nicht unbedingt voneinander abhängig, man kann also auch nur einzelne Dateien tauschen!
EDIT: Wer HMLAN im Einsatz hat, muss auch HMLAN tauschen!

Quellen (v.a.):
HMLAN-keepalive: https://forum.fhem.de/index.php/topic,120600.msg1152020.html#msg1152020
HMinfo - Timerliste: https://forum.fhem.de/index.php/topic,120856.0.html
CUL_HM
- v.a. noch IO-Zuweisungen (Teil 2): https://forum.fhem.de/index.php/topic,123238.0.html
- "undefined subroutine" aus https://forum.fhem.de/index.php/topic,123473.0.html

Grüße,

Beta-User

EDIT: Die diffs gehen jetzt gegen den svn-Stand vom ?
EDIT2: CUL_HM (noch nicht: patch) enthält Stand 20.10. "levelInverse" und einen kleinen Fix in der commandref bzgl. param(s)
EDIT3a: jetzt wieder patch zu CUL_HM anbei

EDIT4a: Stände sind jetzt von 28.10.; habe etwas den Überblick verloren, was da alles drin ist... ::)
HMConfig ist nur für die relevant, die ein sehr spezielles Device haben.

EDIT5: CUL_HM jetzt auf dem Stand von 29.10. Nachmittag, diff liefere ich bei Gelegenheit nach

[OT-Nachtrag noch]
Wer ein HMUARTLGW als (Mit-) IO im Einsatz hat, sollte ab 31.10. per update auf die heute (30.10.) aktualisierte Fassung wechseln :) .

EDIT6: die seit 31.10. via svn verfügbaren Fassungen von HMinfo und HMConfig müßten den letzten hier geposteten gepatchten entsprechen. Die diff lasse ich einstweilen hier für die, die  es genau wissen wollen...
CUL_HM enthält noch kleine Unterschiede, und bei HMLAN gab es wohl beim Einchecken ein Problem.

Weiterer Nachtrag, da hier vermutlich doch grade einige Leute reinschauen - damit die Tool-"Sammlung" komplett ist:
- WebUI [hm.js]:   https://forum.fhem.de/index.php/topic,106959.0.html
- TSCUL&Co: https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796
EDIT: komplette Module entfernt, aktuellere Fassungen gibt es in https://forum.fhem.de/index.php/topic,123874.0.html
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

MadMax-FHEM

#1
Zitat
"Developer"?!? Meistens doch eher "User"

das stimmt ja mittlerweile auch nur noch bedingt ;)

Vielen Dank für die Mühen!
Nat. auch an frank und die Tester!


Ich hab runtergeladen und spiele es nach einem fhem update mal auf meine Testsysteme.
Allerdings ist dort nicht wirklich viel HW angeschlossen und da ich am WE nicht zuhause bin kann ich aktuell auch nicht wirklich viel testen...

Wäre aber dann ein Test von "relativ alt" auf ganz aktuell...
...mal sehen.

EDIT:
1x fhem update (letzter Update bestimmt 3 Monate oder länger), shutdown restart, dann einspielen der neuen Patches (bzw. Full-Dateien) -> keine Auffälligkeiten
(aber halt leider auch nicht wirklich ein "Referenz-System" :-\  )

1x fhem update, Patches (bzw. Full-Dateien) eingespielt und dann shutdown restart -> keine Auffälligkeiten
(aber halt leider auch nicht wirklich ein "Referenz-System" :-\  )

Auf das Hauptsystem kann es dann leider erst frühestens am Mo oder so gehen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Update: Martin hat gestern via  svn updates bereitgestellt. Diese betreffen - zumindest auf den ersten Blick - zum großen Teil andere Themen.

Hoffe, den bisherigen Stand mit den gestrigen Änderungen soweit zusammengeführt zu haben, dass damit alles wieder paßt.

@Martin: wegen https://forum.fhem.de/index.php/topic,123473.0.html wird darum gebeten, die betreffenden Stellen in CUL_HM ggf. bevorzugt zu prüfen!
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

MadMax-FHEM

So ich hab jetzt mal meinem Hauptsystem ein Update verpasst und die Module aus dem Thread eingespielt...

Bislang gut, hab aber außer "shutdown restart" noch nix gemacht ;)

"Auffällig" sind nur folgende Logeinträge:

Zitat
2021.10.18 20:04:55 1: CUL_HM start inital cleanup
2021.10.18 20:04:55 3: Device XYZ added to ActionDetector with 000:20 time

...

2021.10.18 20:05:03 1: CUL_HM finished initial cleanup

Aber das ist schon ok so :)

Ich werde mal "testen" bzw. halt das System "normal" verwenden...
...und melden, wenn etwas auffällig ist.

Noch mal danke, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: MadMax-FHEM am 18 Oktober 2021, 20:11:33
"Auffällig" sind nur folgende Logeinträge:
Vorab: Danke für's Mittesten, es sollte ja auch so sein, dass man "nichts" merkt (oder zumindest nicht mehr als bei der svn-Version).

Diese Einträge (und configCheck -f's) sind normal, das macht auch die reguläre Version so (früher allerdings in nochmal deutlich größerem Umfang ;) )
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

Beta-User

#5
Martin hat übrigens vorhin schon wieder einen großen Teil eingecheckt (wie viel bzw. was nicht, muss ich mir noch ansehen)  :) .
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

BroPi

Mit den aktualisierten Dateien:

10_CUL_HM.pm:?/2021-10-18 UNSTABLE
98_HMinfo.pm:?/2021-10-18 UNSTABLE
00_HMLAN.pm:?/2021-10-18 UNSTABLE

kommen die stündlichen Meldungen:

2021.10.19 08:07:48 3: CUL_HM set VCCU update noArg
2021.10.19 08:07:50 3: CUL_HM set VCCU update noArg

2021.10.19 09:07:48 3: CUL_HM set VCCU update noArg
2021.10.19 09:07:51 3: CUL_HM set VCCU update noArg

jetzt immer doppelt.

frank

#7
Zitat von: Beta-User am 18 Oktober 2021, 20:42:05
Martin hat übrigens vorhin schon wieder einen großen Teil eingecheckt (wie viel bzw. was nicht, muss ich mir noch ansehen)  :) .

zumindestens folgendes habe ich erst einmal erkannt (zeilennummern aus neuer version):

1. zeile 1016 wurde nicht geändert
2. zeile 4998 existiert immer noch
3. zeile 7390ff wurden nicht geändert
4. vor zeile 10880 fehlt jetzt leider (fraglich, ob prefered io noch funktioniert):
    ($iom) = grep {CUL_HM_operIObyIOName($_)} @{$hh->{io}{prefIO}}                  if(!$iom && @{$hh->{io}{prefIO}});

5. zeile 10892 ist nun doppelt
6. zeile 10906 wurde nicht geändert


edit:
7. zeile 10898 reading iodev fehlt
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

#8
Hmm, mal auf die Schnelle ein "sehr inoffizielles" Zwischenupdate mit der Bitte um kritische Durchsicht... (hoffe, das heute abend noch im Echtsystem testen zu können, sonst dauert das ggf. leider länger).

Also: Soweit ich das verstanden habe, hängt das mit CLIENTS eigentlich an HMLAN. Daher habe ich den Teil jetzt weitestgehend auf dem Stand von Martin belassen, dafür aber die CLIENT-Info wieder in HMLAN zusätzlich in den Instanz-Hash eingebaut und die commandref dann auch gleich mit in Angriff genommen (die war aber "komisch", mir ist leider nicht klar, ob jetzt alle Querverweise noch passen).

Die übrigen Zeilen von meiner alten Version sollten wieder eingebaut sein, zudem ist die "Erstdefinition" einer VCCU jetzt hoffentlich stressfrei möglich.

Zu den doppelten stündlichen Meldungen kann ich noch nichts sagen, das kann dauern.

Diffs folgen dann bei Gelegenheit, und wenn jemand das mit den IO-checks nur mit devspec2array testen könnte, wäre es super.
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

frank

Zitatwenn jemand das mit den IO-checks nur mit devspec2array testen könnte, wäre es super.
wenn "Clients" bei einem io unter internals auftaucht und ":CUL_HM:" enthält, funktioniert das auch.

mit "devspec2array('Clients=.*:CUL_HM:.*')" wurden neulich (kurze phase, als meine 00_hmlan.pm auch das internal hatte) bei mir alle 4 io gefunden: cul, hmuart, hmlan und hmusb.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

...ebend, so hatte ich das auch im Kopf...
Daher der update zum HMLAN (einschl. des anderen Patches):
Zitat von: martinp876 am 18 Oktober 2021, 20:32:36
[...] Das mit den "Clients" werden ich noch einmal prüfen. Aus meiner Sicht ist es ein fehlen der Daten in den IOs und sollte dort gelöst werden.
.
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

Beta-User

update im ersten post mit noch ein paar kleineren Änderungen zu heute mittag. Wer HMLAN im Einsatz hat, sollte dringlichst auch die Version von hier verwenden.
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

Beta-User

Zitat von: BroPi am 19 Oktober 2021, 09:37:31
kommen die stündlichen Meldungen:

2021.10.19 08:07:48 3: CUL_HM set VCCU update noArg
2021.10.19 08:07:50 3: CUL_HM set VCCU update noArg

2021.10.19 09:07:48 3: CUL_HM set VCCU update noArg
2021.10.19 09:07:51 3: CUL_HM set VCCU update noArg

jetzt immer doppelt.
Bisher konnte ich sowas bei mir mit den neuesten Versionen von vorhin nicht beobachten, und auch in den alten logs finde ich hier  nichts vergleichbares. Also falls jemand eine Idee hat...?
Sonst suche ich bei Gelegenheit mal nach dem update-Befehl, ob der irgendwie in einer Timer-Schleife aufgerufen wird.
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

Helmi55

Servus
ich habe heute nur das update aus dem svn durchgeführt (bis jetzt war das 10_CUL_HM.pm von den Updates ausgenommen...)
Folgendes ist mir aufgefallen - (habe eine VCCU mir einem HMUart aktuelles FHEM)
Beim Hochfahren habe ich folgende Meldungen im log
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied

und bei einem HM-LC-SW1-FM folgende Meldung
2021.10.20 17:45:56 3: CUL_HM set Bad_Heizung on noArg
2021.10.20 17:45:56 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:45:56 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:45:57 3: CUL_HM set Bad_Heizung off noArg
2021.10.20 17:45:58 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied


Wobei bei einem HM-LC-SW2-FM
ist alles in Ordnung
2021.10.20 17:47:40 3: CUL_HM set Vitrine_Ofen on noArg
2021.10.20 17:47:42 3: CUL_HM set Vitrine_Ofen off noArg


Gruß
Helmut
System1 fhem 6.1 auf RPi 4B mit 4GB, HMUSBConfig, DS9490R-1Wire, Busware USB 868, Pool-Solarsteuerung mit FHEM. System2 fhem 6.1 auf RPi 4B mit 4GB (Bullseye) mit Busware USB 868 und 433 und HMUARTLGW für Haussteuerung

https://www.flickr.com/photos/canonhelmi/

MadMax-FHEM

Ich glaube ja nicht dass die save.file Meldungen vom update/CUL.hm kommen...

Wie sind denn Besitz- und Zugriffsrechte?


ls -la /opt/fhem/log/fhem.save


Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)