Hi,
auch ich habe das Problemchen, dass hier nicht alle HM-Geräte immer mit Strom versorgt sind, und fhem die Geräte, wenn sie nicht antworten, regelmäßig zu erreichen versucht. Das ist nicht schlimm, aber verursacht unnötige Systemlast und Funkverkehr, was ich gerne vermeiden würde. D.h. wenn ich die Geräte stromlos mache, würde ich sie gerne auch in einen Zustand versetzen, dass fhem sie nicht mehr zu erreichen versucht.
Folgende Möglichkeiten habe ich beim Suchen gefunden:
1.attr <Device> autoReadReg 0
2.attr <Device> ignore 1
3.attr <Device> dummy 1
Was ist denn der empfohlene Weg?
ignore lässt das Gerät komplett verschwinden, was vielleicht ein wenig mehr ist, als sein muss.
autoReadReg stellt die statusrequests ab. Reicht das, um den automatischen Funkverkehr zum Device stillzulegen, oder passieren noch andere Abfragen automatisch?
dummy als Attribut... da bin ich aus der CommandRef nicht ganz schlau geworden, das Device wird als Dummy behandelt. Ist das vielleicht der Königsweg, um den Funk abzustellen?
Danke!
Fhem versucht es nur, wenn der action detector aktiv ist. Also actcycle löschen, dann sollte es gut sein.
Danke, das wäre noch ein anderer Weg. actCycle war vorher gar nicht gesetzt.
Mit einem attr <Device> actCycle off geht das Device auf Activity switchedOff
Allerdings ändert sich danach mit einem deleteattr <Device> actCycle der Activity-Status nicht. Auch der Actiondetector meint dann nach wie vor status_Swi_Pump1 switchedOff
status_Swi_Pump2 switchedOff
Also müsste ich wohl actCycle dann nicht löschen, um den alten Status wiederherzustellen, sondern actCycle ausdrücklich setzen. Was ist denn der Standard bzw. was macht für einen HM-LC-SW4-WM Sinn? Wenn ich mir die Readings so anschaue, ändert sich da nix, wenn er nicht geschaltet wird... Ich teste mal 24 Stunden.
Edith sagt: Nachdem ich auch nochmal in den Code von 10_CUL_HM geguckt habe, bin ich überzeugt, dass der Schalter bisher (kein actCylce Attribut) gar nicht im Actiondetector enthalten war. D.h. die Statusrequests können davon nicht gekommen sein...
Dann verstehe ich nicht warum ein statusrequest abgesetzt werden sollte. Hast du da etwas am laufen?
Nö... Ich dachte immer, das sei gewollt? Habe gestern zum Test FHEM extra neu gestartet. Unmittelbar beim Neustart kommt für viele HM Devices:
2016.10.22 17:49:17 3: CUL_HM set Swi_Fstr_Bad_links statusRequest
2016.10.22 17:49:18 3: CUL_HM set Swi_Fstr_Bad_rechts statusRequest
2016.10.22 17:49:19 3: CUL_HM set Swi_Fstr_Gaestebad statusRequest
2016.10.22 17:49:20 3: CUL_HM set Swi_Fstr_Heizungskeller statusRequest
2016.10.22 17:49:21 3: CUL_HM set Swi_Fstr_Vorratskeller statusRequest
2016.10.22 17:49:22 3: CUL_HM set Swi_Fstr_Waschkueche statusRequest
2016.10.22 17:49:23 3: CUL_HM set Swi_Garten_Rasenmaeher statusRequest
2016.10.22 17:49:24 3: CUL_HM set Swi_Garten_Bewaesserung statusRequest
2016.10.22 17:49:25 3: CUL_HM set Swi_Garten_Regensensor statusRequest
2016.10.22 17:49:26 3: CUL_HM set Swi_Garten_RasPi statusRequest
2016.10.22 17:49:27 3: CUL_HM set Swi_Pump1_1_blau statusRequest
2016.10.22 17:49:28 3: CUL_HM set Swi_Pump1_2_braun statusRequest
2016.10.22 17:49:29 3: CUL_HM set Swi_Pump1_3_gelb statusRequest
2016.10.22 17:49:30 3: CUL_HM set Swi_Pump1_4 statusRequest
2016.10.22 17:49:31 4: CUL_HM_Resend: Swi_Pump1 nr 2
2016.10.22 17:49:32 3: CUL_HM set Swi_Pump2_1_gruen statusRequest
2016.10.22 17:49:33 3: CUL_HM set Swi_Pump2_2_weiss statusRequest
2016.10.22 17:49:34 3: CUL_HM set Swi_Pump2_3_rosa statusRequest
2016.10.22 17:49:35 3: CUL_HM set Swi_Pump2_4 statusRequest
2016.10.22 17:49:36 3: CUL_HM set Swi_Strom_Garten statusRequest
2016.10.22 17:49:37 4: CUL_HM_Resend: Swi_Pump1 nr 3
2016.10.22 17:49:42 4: CUL_HM_Resend: Swi_Pump1 nr 4
Und das nudelt er dann, da die Geräte(Swi_Pump(1|2) mit den Kanälen) nicht antworten, wohl immer wieder durch, ziemlich genau im Halbstundentakt:
2016.10.23 03:35:24 3: CUL_HM set Swi_Pump1_1_blau statusRequest
2016.10.23 03:35:25 3: CUL_HM set Swi_Pump1_2_braun statusRequest
2016.10.23 03:35:26 3: CUL_HM set Swi_Pump1_3_gelb statusRequest
2016.10.23 03:35:26 4: CUL_HM_Resend: Swi_Pump1 nr 2
2016.10.23 03:35:27 3: CUL_HM set Swi_Pump1_4 statusRequest
2016.10.23 03:35:28 3: CUL_HM set Swi_Pump2_1_gruen statusRequest
2016.10.23 03:35:30 3: CUL_HM set Swi_Pump2_2_weiss statusRequest
2016.10.23 03:35:31 4: CUL_HM_Resend: Swi_Pump1 nr 3
2016.10.23 03:35:31 3: CUL_HM set Swi_Pump2_3_rosa statusRequest
2016.10.23 03:35:32 3: CUL_HM set Swi_Pump2_4 statusRequest
2016.10.23 03:35:36 4: CUL_HM_Resend: Swi_Pump1 nr 4
[...]
2016.10.23 04:05:45 3: CUL_HM set Swi_Pump1_1_blau statusRequest
2016.10.23 04:05:46 3: CUL_HM set Swi_Pump1_2_braun statusRequest
2016.10.23 04:05:46 4: CUL_HM_Resend: Swi_Pump1 nr 2
2016.10.23 04:05:47 3: CUL_HM set Swi_Pump1_3_gelb statusRequest
2016.10.23 04:05:48 3: CUL_HM set Swi_Pump1_4 statusRequest
2016.10.23 04:05:49 3: CUL_HM set Swi_Pump2_1_gruen statusRequest
2016.10.23 04:05:52 4: CUL_HM_Resend: Swi_Pump1 nr 3
2016.10.23 04:05:52 3: CUL_HM set Swi_Pump2_2_weiss statusRequest
2016.10.23 04:05:53 3: CUL_HM set Swi_Pump2_3_rosa statusRequest
2016.10.23 04:05:54 3: CUL_HM set Swi_Pump2_4 statusRequest
2016.10.23 04:05:57 4: CUL_HM_Resend: Swi_Pump1 nr 4
[...]
2016.10.23 04:36:06 3: CUL_HM set Swi_Pump1_1_blau statusRequest
2016.10.23 04:36:07 3: CUL_HM set Swi_Pump1_2_braun statusRequest
2016.10.23 04:36:08 4: CUL_HM_Resend: Swi_Pump1 nr 2
2016.10.23 04:36:08 3: CUL_HM set Swi_Pump1_3_gelb statusRequest
2016.10.23 04:36:09 3: CUL_HM set Swi_Pump1_4 statusRequest
2016.10.23 04:36:10 3: CUL_HM set Swi_Pump2_1_gruen statusRequest
2016.10.23 04:36:12 4: CUL_HM_Resend: Swi_Pump1 nr 3
2016.10.23 04:36:13 3: CUL_HM set Swi_Pump2_2_weiss statusRequest
2016.10.23 04:36:15 3: CUL_HM set Swi_Pump2_3_rosa statusRequest
2016.10.23 04:36:16 3: CUL_HM set Swi_Pump2_4 statusRequest
2016.10.23 04:36:17 4: CUL_HM_Resend: Swi_Pump1 nr 4
[...]
2016.10.23 05:06:27 3: CUL_HM set Swi_Pump1_1_blau statusRequest
2016.10.23 05:06:29 3: CUL_HM set Swi_Pump1_2_braun statusRequest
2016.10.23 05:06:30 3: CUL_HM set Swi_Pump1_3_gelb statusRequest
2016.10.23 05:06:31 4: CUL_HM_Resend: Swi_Pump1 nr 2
2016.10.23 05:06:31 3: CUL_HM set Swi_Pump1_4 statusRequest
2016.10.23 05:06:32 3: CUL_HM set Swi_Pump2_1_gruen statusRequest
2016.10.23 05:06:34 3: CUL_HM set Swi_Pump2_2_weiss statusRequest
2016.10.23 05:06:36 3: CUL_HM set Swi_Pump2_3_rosa statusRequest
2016.10.23 05:06:37 4: CUL_HM_Resend: Swi_Pump1 nr 3
2016.10.23 05:06:37 3: CUL_HM set Swi_Pump2_4 statusRequest
2016.10.23 05:06:42 4: CUL_HM_Resend: Swi_Pump1 nr 4
[...]
2016.10.23 05:36:48 3: CUL_HM set Swi_Pump1_1_blau statusRequest
2016.10.23 05:36:50 3: CUL_HM set Swi_Pump1_2_braun statusRequest
2016.10.23 05:36:51 3: CUL_HM set Swi_Pump1_3_gelb statusRequest
2016.10.23 05:36:51 4: CUL_HM_Resend: Swi_Pump1 nr 2
2016.10.23 05:36:52 3: CUL_HM set Swi_Pump1_4 statusRequest
2016.10.23 05:36:53 3: CUL_HM set Swi_Pump2_1_gruen statusRequest
2016.10.23 05:36:55 3: CUL_HM set Swi_Pump2_2_weiss statusRequest
2016.10.23 05:36:56 4: CUL_HM_Resend: Swi_Pump1 nr 3
2016.10.23 05:36:57 3: CUL_HM set Swi_Pump2_3_rosa statusRequest
2016.10.23 05:36:58 3: CUL_HM set Swi_Pump2_4 statusRequest
2016.10.23 05:37:01 4: CUL_HM_Resend: Swi_Pump1 nr 4
[etc.]
Abstellen kann ich die Sendeversuche wohl (jedenfalls für einige Zeit), indem ich den Devices Strom gebe. Aber eigentlich wollte ich sie ja abgeschaltet lassen, wenn ich sie nicht brauche (das ganze Gerödel im Garten im Winterhalbjahr). Daher die Frage nach dem Deaktiveren von Devices.
Bei Neustart ist es gewollt. Kann über autoreadreg abgeschaltet werden.
Ich werde es mir ansehen, da bei ignore ni HT gesendet werden darf. Das wäre ein bug.
Ansonsten ist es gewünscht den Status zu prüfen t. Devices welche eingetragen sind müssen einen Status melden. Alle 30min probieren sollte ok sein.
nutzt du das attribut actAutoTry?
Nein, das Attribut ist nicht gesetzt.