Fehlermeldung "HMLAN1 does not support CUL_HM" IOList VCCU

Begonnen von dancatt, 08 September 2021, 10:24:03

Vorheriges Thema - Nächstes Thema

Beta-User

#30
Nachbrenner noch:
Eigentlich müßte mAn. der Check der IOList für alle VCCU vorgezogen werden, also eine Schleife vor der Schleife eingebaut werden. Damit wäre sichergestellt, dass auch der Teil "cfg-Reihenfolge-fest" wäre?

Angepaßter Code anbei...

(Nicht wundern, dass ich da nicht eine eigene devspec2array verwendet habe; da wir genau wissen, dass wir bei der vorhandenen Auswahl genau ein Argument checken müssen, dürfte das so herum schneller sein...)

EDIT: Anhang gelöscht, ist im Nachbarthread konsolidiert&aktualisiert
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

dancatt

Alles drin, Neustart gemacht.
Nun schauen wir mal. Bis jetzt scheint alles ok.
Hoffe dass die ganzen Patches auch mal ins SVN kommen.
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Danke für die Rückmeldung.

Hast du irgendwo aes aktiviert?

Wäre nett, wenn jemand noch Rückmeldung geben könnte, der das feature nutzt.

Ich mach' dann bei Gelegenheit mal einen Gesamtpatch fertig (ohne HMUARTLGW, das betrifft mgernoth) und bin mal optimistisch, dass Martin sich dazu auch irgendwann melden wird (und sei es nur, dass er "ok" meldet und ein anderer Maintainer das dann für ihn ins svn schubst...).
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

martinp876

bei HMLAN wird Clients im Modul gesetzt (wie bei manchen anderen auch) - aber nicht in die Entity kopiert.

Ich ändere das Verhalten nicht, da es mit usus erscheint.

in CUL_HM hatte ich das nicht berücksichtigt: wenn die Entity kein Internal Clients hat muss ich in Modul nachsehen.
Ist jetzt drin.

Also workaround hättet ihr einfach erzwingen können
{$defs{HMLAN1}{Clients} = ":CUL_HM:"}

Beta-User

Danke für die Rückmeldung, wieder was gelernt :) .

Bzgl. des HMLAN-patches: Da war neben dieser - nunmehr mit 24961 obsoleten - Verschiebung dann auch noch der ältere Patchvorschlag von frank ([hmlan] patch: keepAlive mechanismus ursache für gelegentliche hmlan reboots) drin. Hat sicher nicht die hohe Prio wie die anderen aktuellen Problemchen, es wäre aber nett, wenn es nicht unterginge (oder frank eine Rückmeldung bekäme, warum nicht).
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

dancatt

Moin,

die HMLAN kommt aber noch nicht mit dem Update.

Gruß Daniel
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

Beta-User

Zitat von: dancatt am 14 September 2021, 07:36:19
die HMLAN kommt aber noch nicht mit dem Update.
...muss sie ja auch nicht, Martin hat das bzgl. des Clients-Themas etwas anders (=eleganter) gelöst.

Bzgl. HMLAN wären m.E. zwei Dinge wünschenswert:
- eine Rückmeldung zum Patchvorschlag von frank
- eine Aktualisierung der commandref in Richtung "id". Du kannst ja letzteres gerne als patch beisteuern, das ist nichts großes, siehe z.B. auch die Änderungen (nach =pod bzw. =html) in https://svn.fhem.de/trac/changeset/24963/trunk/fhem/FHEM/98_weekprofile.pm
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

Amenophis86

Ich hänge mich mal hier dran. Wollte bei einem neuen System jetzt eine VCCU anlegen und den HMLAN1 dazu packen in die IOList aber der Fehler does not ... kommt immer noch. Ist das Problem immer noch nicht behoben, oder habe ich was übersehen? FHEM habe ich eben gerade ein Update unterzogen aber es bleibt dabei.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Beta-User

Kannst du mal "version" von CUL_HM ausdrücklich gegenchecken?
Mit der letzten aus dem svn (24961) müßte das eigentlich klappen.
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

Amenophis86

# $Id: 10_CUL_HM.pm 24961 2021-09-12 06:46:07Z martinp876 $

Habe auch noch einige andere Fehler gehabt, die ich hier in den letzten Tagen gesehen habe. DeviceRename hat dazu geführt, dass erst nach einem Restart die Internals entsprechend angepasst wurden.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Beta-User

Hmm, komisch. Zumindest das sollte eigentlich mit der svn klappen...

Aber du kannst gerne "meine" gepatchte Fassung aus dem Nachbarthread mal testen, wobei die diesen Punkt eigentlich auch nicht (mehr) anders macht als die svn-Fassung.
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

Amenophis86

Hatte gestern alles per Hand angelegt und geändert gehabt, da ich voran kommen musste. Wenn ich die Tage Zeit habe, dann schaue ich nochmal nach.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

khk123

Ich bekomme bei der Einrichtung der VCCU den Fehler

VCCU: unknown attribute IOList. Type 'attr VCCU ?' for a detailed list


Folgendes PM ist aktiv:

10_CUL_HM.pm 25059 2021-10-10 07:50:22Z martinp876


Def der VCCU:

defmod VCCU CUL_HM xxxxxx
attr VCCU .mId FFF0
attr VCCU DbLogExclude .*
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update

setstate VCCU CUL868:UAS,
setstate VCCU 2021-10-16 18:55:40 IOopen 0
setstate VCCU 2021-10-16 18:55:40 state CUL868:UAS,


Mach ich etwas falsch?

Viele Grüße
Karlheinz
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

frank

speichere, was du schon hast, mach fhem restart und probiere erneut.
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

khk123

Danke für den Hinweis. Hat funktioniert. Nur warum braucht es da einen Neustart?

FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa