[gelöst] CUL_HM legt fremde Geräte an obwohl autocreate ausgeschaltet ist

Begonnen von kadettilac89, 13 April 2021, 12:27:03

Vorheriges Thema - Nächstes Thema

kadettilac89

ich habe autocreate disabled (attr autocreate disable 1). Dennoch werden irgend welche Geräte angelegt die nicht zu meiner Installation gehören. Wie kann ich das Anlegen verhindern?

Ich  vermutlich ein Bug. Ich möchte nicht jede Nacht einen Reboot durchführen nur damit die ungespeicherten Geräte verschwinden.

Mein Setup
- Fhem aktuell
- VCCU
- Device HMLANGW (geflashte CCU2)
- autocreate disabled

Mit alter CUL_HM Version werden keine Devices angelegt, die arbeitet wie gewünscht. Test mit "# $Id: 10_CUL_HM.pm 16588 2018-04-11 18:21:53Z martinp876 $

Beispiel eines Devices das ungewollt angelegt wurde ...

defmod HM_5B1456 CUL_HM 5B1456
attr HM_5B1456 .mId 6610
attr HM_5B1456 DbLogExclude .*
attr HM_5B1456 IODev HMLANGW
attr HM_5B1456 IOgrp VCCU
attr HM_5B1456 autoReadReg 4_reqStatus
attr HM_5B1456 event-on-change-reading state
attr HM_5B1456 expert rawReg
attr HM_5B1456 firmware 11.2
attr HM_5B1456 model unknown
attr HM_5B1456 room 1NEW
attr HM_5B1456 serialNr ��]cj̴�9
attr HM_5B1456 subType no

setstate HM_5B1456 RESPONSE TIMEOUT:RegisterRead
setstate HM_5B1456 2021-04-13 10:07:40 .D-devInfo 55EF3E
setstate HM_5B1456 2021-04-13 10:07:40 .D-stc 01
setstate HM_5B1456 2021-04-13 10:07:45 .associatedWith HM_5B1456,HM_5B1456
setstate HM_5B1456 2021-04-13 10:07:40 .protLastRcv 20210413100740
setstate HM_5B1456 2021-04-13 10:07:40 D-firmware 11.2
setstate HM_5B1456 2021-04-13 10:07:40 D-serialNr ��]cj̴�9
setstate HM_5B1456 2021-04-13 11:01:00 RegL_00.
setstate HM_5B1456 2021-04-13 10:07:49 cfgState updating
setstate HM_5B1456 2021-04-13 10:08:09 commState CMDs_done_Errors:1
setstate HM_5B1456 2021-04-13 10:08:09 state RESPONSE TIMEOUT:RegisterRead

frank

ZitatTest mit "# $Id: 10_CUL_HM.pm 16588 2018-04-11 18:21:53Z martinp876 $
na das ist ja mal ein vergleich.
nur 10_CUL_HM.pm geändert?
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

kadettilac89

ich sag mal ja. Ein Enduser hat nie was geändert :)

lange version, ich hatte vorher in der VCCU CUL mit der speziellen TS-Firmware. Vor ein paar Wochen habe ich dann eine günstige CCU2 in die Hände bekommen und diese mit der Gateway FW geflasht. In diesem Aufwasch habe ich dann wieder die "originalen" HM-Module geladen. Es funktioniert auch alles, jedoch habe ich einige Devices in Fhem die mir nicht gehören.

Für die TS-Firmware werden viele HM-Module, auch die 10_CUL_HM.pm,  "exclude from update".

Der Vergleich mit der alten Version da ich diese aus dem Backup genommen habe - VOR TS Firmware ... 2 Jahre alt.

Es kann natürlich sein, dass die TS-Firmware und die originale HM-Module ein klein wenig anders arbeiten. Wobei ich bei meinen Heizkörperthermostaten alle Channel drin habe (nichts gelöscht oder so). Wollte mir das neu pairen zum Schluss aufheben, erstmal hier fragen. Meine Geräte haben gute RSSI, es werden auch welche mit -137 db gesammelt, ich zweifle, dass es fehlende Channel sind die erneut angelegt werden.

Werde mal ein paar HM_CUL testen, die ganz alle funktioniert ja. Definition funktionieren = legt nichts an und schaltet bzw. liest Sensoren wie gewünscht.

noansi

Hallo kadettilac89,

Zitatich habe autocreate disabled (attr autocreate disable 1). Dennoch werden irgend welche Geräte angelegt die nicht zu meiner Installation gehören. Wie kann ich das Anlegen verhindern?

Ich  vermutlich ein Bug. Ich möchte nicht jede Nacht einen Reboot durchführen nur damit die ungespeicherten Geräte verschwinden.
Nein, kein Bug, das ist ein Feature. Unbekannte Geräte mit passendem Messagetype werden jetzt immer angelegt, jedoch nur gepaired, wenn auch hmPairForSec zuvor gesetzt wurde.
Martin hat es im Code in einem der letzten updates geändert, warum weiß ich nicht.

Zumindest scheitert ein Pairing so nicht, weil autocreate nicht beachtet wurde.

Gruß, Ansgar.

kadettilac89

Zitat von: noansi am 13 April 2021, 19:07:44
Hallo kadettilac89,
Nein, kein Bug, das ist ein Feature. Unbekannte Geräte mit passendem Messagetype werden jetzt immer angelegt, jedoch nur gepaired, wenn auch hmPairForSec zuvor gesetzt wurde.
Martin hat es im Code in einem der letzten updates geändert, warum weiß ich nicht.

Zumindest scheitert ein Pairing so nicht, weil autocreate nicht beachtet wurde.

Gruß, Ansgar.

Ok, würde das Verhalten erklären. Weißt du wann das geändert wurde? Suche mir dann die Version die das Feature noch nicht hat und schließe es dann vom Update aus.

noansi

Hallo kadettilac89,

ZitatWeißt du wann das geändert wurde? Suche mir dann die Version die das Feature noch nicht hat und schließe es dann vom Update aus.
Nein. Und ich halte das auch für keine gute Idee.

Persönlich fände ich es besser, autocreate wieder mit rein zu nehmen oder eine andere Einstellmöglichkeit in CUL_HM bei der VCCU dieses Neuanlegen fremder Geräte ohne Pairing Wunsch zu unterdrücken.

Gruß, Ansgar.

enno

Moin zusammen,

Rudi hatte mal geschrieben, dass ein Gerät das angelegt ist und dann auf "ignore" steht weniger Ressourcen verbraucht als wenn es nicht angelegt wurde und immer wieder auftaucht... Daher ist bei mir autocreate aktiv, aber die neuen Device bekommen gleich das Attribut "ignore".

https://forum.fhem.de/index.php/topic,117805.msg1123622.html#msg1123622

Gruss
  enno
Einfacher FHEM Anwender auf Intel®NUC

kadettilac89

Danke an alle. Für mich reicht die Information "works as designed".

Meine persönliche Lösung - ältere Version legt kein ungewollten Geräte mehr an. Solange sonst alles funktionert bleibt die alte Version im System. Kann aber jeder handhaben wie er will.

Zitat von: enno am 14 April 2021, 20:17:57
Rudi hatte mal geschrieben, dass ein Gerät das angelegt ist und dann auf "ignore" steht weniger Ressourcen verbraucht als wenn es nicht angelegt wurde und immer wieder auftaucht... Daher ist bei mir autocreate aktiv, aber die neuen Device bekommen gleich das Attribut "ignore".

Mag sein, aber ich habe eine Hausautomatisierung um mir Arbeit abzunehmen. Dann will ich nicht manuell irgend welche ungewollten Devices auf ignore setzen. Aus diesem Grund ist autocreate aus. Wenn das mehr Resourcen benötigt .. ist halt so. Mein Container dümpelt mit 0,7 - 2% CPU Last rum, die paar zusätzlichen Events merkt der nicht ...

frank

was mir jetzt gerade durch den kopf geht:
an diese angelegten devices werden doch dann auch bei jedem neustart ggf automatische statusrequest gesendet, oder?
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

kadettilac89

Zitat von: frank am 15 April 2021, 09:44:50
an diese angelegten devices werden doch dann auch bei jedem neustart ggf automatische statusrequest gesendet, oder?
ich kann dir nicht folgen ... vielleicht rede ich jetzt von was anderem als du meintest.

Aktuelles Verhalten, Geräte werden trozt autocreate = off angelegt. Dann sind die erstmal da. Im Anschluss wäre die Idee solche Geräte mit ignore auszublenden. Dann gäbe es statusrequests, jedoch sind die Geärte nur halb "fertig". Die wären dann erstmal im Status timeout und cmd failed. Später glaub ich sind die dann "dead".

Wenn ich die alte Version von 10_CUL_HM behalte dann wird nichts angelegt. Dann muss auch kein Status geprüft und reportet werden. Das einzige sind Readings in der VCCU "unknown_5B1456 received" oder ähnlich. Diese habe ich aber per defIgnUnknown gelöscht.

frank

Zitatich kann dir nicht folgen ...
:) :) :)


ZitatAktuelles Verhalten, Geräte werden trozt autocreate = off angelegt. Dann sind die erstmal da. Im Anschluss wäre die Idee solche Geräte mit ignore auszublenden. Dann gäbe es statusrequests, jedoch sind die Geärte nur halb "fertig". Die wären dann erstmal im Status timeout und cmd failed. Später glaub ich sind die dann "dead".
dazu müsste man ja erst einmal wissen, dass sie existieren.

wenn sie nicht auf ignore gesetzt sind, werden sie als deine angesehen und entsprechend gehandelt.
als beispiel hast du im ersten post ein device gezeigt.
die readings zeigen, dass fhem cmds an das device gesendet hat. wenn du nicht manuell cmds ausgelöst hast, wurden diese automatisch gesendet.
das finde ich gar nicht gut! und der nachbar sicherlich auch nicht.

um sie dead zu setzen, müsste es attr actCycle geben.
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

Otto123

Zitat von: kadettilac89 am 15 April 2021, 12:16:24
Diese habe ich aber per defIgnUnknown gelöscht.
Glaube ich nicht :)
ZitatCCU_FHEM
defIgnUnknown
Definieren die unbekannten Devices und setze das Attribut ignore. Ddann loesche die Readings.
Also Du legst sie an, Du löschst sie nicht. Da kannst Du auch den neuen Mechanismus lassen :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

mcfly71

Servus Gemeinde,

ich würde gerne auch etwas zu dem Thema sagen, auch wenn gelöst, auch wenn es nervig ist. Ich schließe mich
definitiv dem Ersteller des Threads an. Wenn ein Parameter names autocreate auf disabled steht, sollte nichts, garnichts
von selbst angelegt werden. Ich habe mich damit zwar abgefunden, aber da es hier auf dem tableau liegt, wollte ich etwas
dazu sagen.
Das Problem bei mir: Ich installiere für einen Freund ebenfalls ein fhem mit vielen Homematic Geräten. Ich stelle dieses
Freund-FHem auf autocreate = enabled und lerne ein neues Device an.... danach mist dieses Device in meinem System
ebenfalls vorhanden, das ? steht beim Speichern der Config (natürlich steht im device in meinem System: paired to IDdesAnderenSystems), und ich muss auf jedenfall das device bei mir wieder löschen. Sehr sehr hänselig und überhaupt nicht schlüssig.

LG
mcfly
- HMLAN / Raspberry auf hmmode
- Homematic