Autor Thema: Icons schalten alle An wenn ich einen Schalter drücke  (Gelesen 1804 mal)

Offline S7EN

  • New Member
  • *
  • Beiträge: 10
Icons schalten alle An wenn ich einen Schalter drücke
« am: 16 Oktober 2018, 09:29:13 »
Hallo zusammen,

ich habe das Problem, dass wenn ich eine meiner Deckenlampen auf "An" stelle, die Icons der anderen Deckenlampen auch auf "An" gehen. Es werden zwar keine Befehle gesendet, das die anderen Deckenlampen auch "An" geschalten werden sollen, aber die Symbole sind auf "An". Ich hoffe ihr könnt mir helfen, es ist nämlich sehr nervig. Die Nummern der beiden Geräte unterscheiden sich ja, ich weiß nicht wie die zusammen hängen dass dies passiert. Bilder im Anhang.

« Letzte Änderung: 16 Oktober 2018, 09:32:46 von S7EN »

Offline RaspiLED

  • Hero Member
  • *****
  • Beiträge: 2451
  • Es begann alles so klein ;-)
Antw:Icons schalten alle An wenn ich einen Schalter drücke
« Antwort #1 am: 16 Oktober 2018, 09:51:53 »
Hi,
Mach mal ein generelles verbose 5 mit nachgelegtem einschalten und dann das log hier rein.
Beim Ausschalten auch alle aus?
Benutzt Du doif oder andere dinge insbesondere mit Reaktion auf Deckenlampe*
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Offline S7EN

  • New Member
  • *
  • Beiträge: 10
Antw:Icons schalten alle An wenn ich einen Schalter drücke
« Antwort #2 am: 16 Oktober 2018, 12:05:11 »
Hi, das steht im Logfile nach nem Restart und nach drücken der einzelnen Schalter.

2018.10.16 12:01:40 1: Logfile gelöscht
2018.10.16 12:01:46 0: Server shutdown
2018.10.16 12:01:47 1: Including fhem.cfg
2018.10.16 12:01:48 3: WEB: port 8083 opened
2018.10.16 12:01:48 2: eventTypes: loaded 424 events from ./log/eventTypes.txt
2018.10.16 12:01:49 1: cm: did not find suitable IODev (CUL etc. in rfmode MAX)! You may want to execute 'attr cm IODev SomeCUL'
2018.10.16 12:01:49 3: WEBphone: port 8084 opened
2018.10.16 12:01:49 2: ESPEasy espBridge: Opening bridge v2.00 [TCP:IPV4:8383]
2018.10.16 12:01:49 3: espBridge: port 8383 opened
2018.10.16 12:01:50 2: Registering GEOFANCY geofancy for URL /geo...
2018.10.16 12:01:50 3: Opening CUL_0 device /dev/ttyACM0
2018.10.16 12:01:50 3: Setting CUL_0 serial parameters to 9600,8,N,1
2018.10.16 12:01:50 3: CUL_0: Possible commands: ABCEeFGhiKkLlMmRTtUuVWXxY
2018.10.16 12:01:50 3: CUL_0 device opened
2018.10.16 12:01:50 1: Including ./log/fhem.save
2018.10.16 12:01:51 0: Featurelevel: 5.9
2018.10.16 12:01:51 0: Server started with 53 defined entities (fhem.pl:17488/2018-10-08 perl:5.024001 os:linux user:fhem pid:23721)
2018.10.16 12:01:51 3: telnetForBlockingFn_1539684111: port 35159 opened
2018.10.16 12:02:08 3: CUL_0 IT_set: Deckenlampe_Wohnzimmer on
2018.10.16 12:02:14 3: CUL_0 IT_set: Deckenlampe_Wohnzimmer off
2018.10.16 12:02:19 3: CUL_0 IT_set: Deckenlampe_Schlafzimmer on
2018.10.16 12:02:22 3: CUL_0 IT_set: Deckenlampe_Schlafzimmer off
2018.10.16 12:02:23 3: CUL_0 IT_set: Deckenlampe_Flur on
2018.10.16 12:02:24 3: CUL_0 IT_set: Deckenlampe_Flur off
2018.10.16 12:02:25 3: CUL_0 IT_set: Deckenlampe_Bad on
2018.10.16 12:02:27 3: CUL_0 IT_set: Deckenlampe_Bad off
2018.10.16 12:02:30 3: CUL_0 IT_set: Deckenlampe_Flur on
2018.10.16 12:02:31 3: CUL_0 IT_set: Deckenlampe_Flur off

Verbose steht auf 5 und DOIF's sind keine hinterlegt für das "An" oder "Aus" der Deckenlampen. Das ganze passiert dann auch beim Ausschalten der Lampen, alle Symbole gehen auf aus. Ich habe nun bemerkt, das die "State"sich auch bei den anderen Deckenlampen auf "On" ändert, wenn ich eine der Lampen einschalte. Merkwürdig.
« Letzte Änderung: 16 Oktober 2018, 12:41:41 von S7EN »

Offline S7EN

  • New Member
  • *
  • Beiträge: 10
Antw:Icons schalten alle An wenn ich einen Schalter drücke
« Antwort #3 am: 21 Oktober 2018, 07:37:53 »
Keiner ne Idee mehr?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15323
  • "Developer"?!? Meistens doch eher "User"
Antw:Icons schalten alle An wenn ich einen Schalter drücke
« Antwort #4 am: 21 Oktober 2018, 08:17:42 »
Bilder ansehen ist Mist, das log sieht OK aus, jedenfalls, wenn es so war, dass da manuelle Schaltvorgänge die Ursache waren. Dann dürfte im Event-Monitor auch nicht mehr zu sehen sein?

Was war das für ein Schalten? FHEMWEB oder Fernbedienung? Ist es gleich, wenn du die andere Methode nimmt?

Mach mal ein list von einem der devices, insbesondere. devStateIcon könnte interessant sein.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline S7EN

  • New Member
  • *
  • Beiträge: 10
Antw:Icons schalten alle An wenn ich einen Schalter drücke
« Antwort #5 am: 21 Oktober 2018, 09:00:47 »
Hi, habs hinbekommen und auch beim Ausschalten werden jetzt nicht mehr alle Lampen ausgeschalten.

Die Lösung war das x sowie den off Befehl in der DEF "1527x65739 1111 1000" zu "1527165739 1111 0111" zu ändern. Die Zahl statt dem x ist random, dort kann man auch Buchstaben einfügen, der Off Befehl von früher, war der "Alles Aus" Button der Fernbedienung, klar das dann alles aus geht. Aber man muss ein wenig rumspielen wenn FHEM das Protokoll der Wandschalter nicht kennt.
Diese sind übrigens von Pollin unter der Marke Daycom und hatten 18€ für 3 Stk. inkl. Fernbedienung gekostet. Pollin bietet auch Dimmer an, dann sollte die DEF auch geändert werden, ich denke dann auf "1527165739 1111 0111 1111 0111".

Danke trotzdem für die Hilfe.

« Letzte Änderung: 21 Oktober 2018, 09:05:42 von S7EN »

Offline Pfriemler

  • Hero Member
  • *****
  • Beiträge: 3913
  • geht nich gips nich
Antw:Icons schalten alle An wenn ich einen Schalter drücke
« Antwort #6 am: 08 August 2021, 13:13:40 »
edit2 och nö...!!!!!

vorweg: Weiteres nur für Ursachenforscher. Ein simpler Neustart von FHEM hat alle beschriebenen Abhängigkeiten behoben. Anscheinend geriet die notify-Tabelle durch das Copy&Paste bei der Definition der Geräte durcheinander. Passieren dürfte das aber irgendwie dennoch nicht.
Egal, Problem scheint gelöst.

----

Ich hole den Fred mal hoch, weil S7en's Lösung mir eher nach einem Workaround klingt, das Problem aber vermutlich ein anderes ist und weiterhin existiert.

Habe (selbst völlig neu) ein Rudel IT-Steckdosen (Brennenstuhl AB440S und ähnliche) aktuell am Ausprobieren hier und kann diesen seltsamen Effekt hier auch beobachten. Die Definitionen sind neu, die Geräte sind nirgends eingebunden, ich nutze IT bisher noch gar nicht. Es ist also ausgeschlossen, dass irgendwas "dazzwischenfunkt".

Die bisher definierten AB440S und ELROS
defmod BSS_A IT FF0FF0FFFF FF F0
defmod BSS_B IT FF0FFF0FFF FF F0
defmod BSS_C IT FF0FFFF0FF FF F0
defmod BSS_D IT FF0FFFFF0F FF F0
defmod BSS_E  IT FF0FFFFFF0 FF F0
defmod ELRO_2E IT 0FFFF0FFFF FF F0
defmod ELRO_2C IT 00FFF00FFF FF F0
also die BSS nutzen einen gleichen Hauscode und jeweils nur den passend gekippten DIP A-E., die ELROs sind gänzlich anders.

Schalten aus FHEM lassen sich alle Steckdosen einwandfrei. Allerdings meint FHEM, dass bei zwei Steckdosen auch andere Steckdosen geschaltet werden:
- set BSS_D on/off schaltet in der GUI auch BSS_A, BSS_B, BSS_C und BSS_E ein und aus.
- set ELRO_2C on/off schaltet in der GUI auch ELRO_2E und BSS_D (!) mit.

Die dazu passenden Events werden auch im Eventmonitor angezeigt.

2021-08-08 12:58:33 IT BSS_B on
2021-08-08 12:58:33 IT BSS_D on
2021-08-08 12:58:33 IT BSS_A on
2021-08-08 12:58:33 IT BSS_C on
2021-08-08 12:58:33 IT BSS_E on
2021-08-08 12:58:35 IT BSS_B off
2021-08-08 12:58:35 IT BSS_D off
2021-08-08 12:58:36 IT BSS_A off
2021-08-08 12:58:36 IT BSS_C off
2021-08-08 12:58:36 IT BSS_E off

Geschaltet wird aber aber nur BSS_D wie befehligt. Beachtet: das Event für _D erscheint erst als zweites!
Ebenso erzeugt set ELRO_2C off die Events
2021-08-08 13:07:46 IT BSS_D off
2021-08-08 13:07:46 IT ELRO_2E off
2021-08-08 13:07:46 IT ELRO_2C off
hier der eigentliche Auslöser sogar als drittes.

Sende ich hingegen explizit bspw. "set ELRO_2C,ELRO_2E on", ergibt das im Eventmonitor ebenso
2021-08-08 13:10:32 IT BSS_D on
2021-08-08 13:10:32 IT ELRO_2E on
2021-08-08 13:10:32 IT ELRO_2C on
2021-08-08 13:10:33 IT ELRO_2E on
und es schalten auch beide ELRO-Dosen. Auch hier erzeugt der Schaltbefehl für ELRO_2C zunächst Events für BSS_D und ELRO_2E mit, erst beim zweiten Event schaltet die ELRO_2E auch wirklich.

Mir scheint, dass bei den fraglichen Fehlern immer nur ein Code gesendet wird, FHEM aber aus welchen Gründen auch immer meint, dort mehrere Events zu erkennen und entsprechend umzusetzen.

Natürlich kann ich auch hier wieder auf Workaround gehen und die betreffenden Codes ändern, aber ich frage mich, was da hinter den Kulissen tatsächlich läuft...

edit: set ELRO_2C off mit verbose 5 im LOG:
2021.08.08 13:18:21 5: POST /fhem?cmd.ELRO_2C=set%20ELRO_2C%20off& ....
2021.08.08 13:18:21 5: Cmd: >set ELRO_2C off<
2021.08.08 13:18:21 3: CUL433 IT_set: ELRO_2C off
2021.08.08 13:18:21 5: Starting notify loop for BSS_D, 1 event(s), first is off
2021.08.08 13:18:21 5: Wasserzaehler : WaterCalculator Begin_______________________________________________________________________________________________________________________________
2021.08.08 13:18:21 5: Wasserzaehler : WaterCalculator - Notify - Trigger Dev Name                                                : BSS_D
2021.08.08 13:18:21 5: End notify loop for BSS_D
2021.08.08 13:18:21 5: Starting notify loop for ELRO_2E, 1 event(s), first is off
2021.08.08 13:18:21 5: Wasserzaehler : WaterCalculator Begin_______________________________________________________________________________________________________________________________
2021.08.08 13:18:21 5: Wasserzaehler : WaterCalculator - Notify - Trigger Dev Name                                                : ELRO_2E
2021.08.08 13:18:21 5: End notify loop for ELRO_2E
2021.08.08 13:18:21 5: Starting notify loop for ELRO_2C, 1 event(s), first is off
2021.08.08 13:18:21 5: Wasserzaehler : WaterCalculator Begin_______________________________________________________________________________________________________________________________
2021.08.08 13:18:21 5: Wasserzaehler : WaterCalculator - Notify - Trigger Dev Name                                                : ELRO_2C
2021.08.08 13:18:21 5: End notify loop for ELRO_2C
2021.08.08 13:18:21 5: CUL433 IT_set: Type=CUL Protocol=V1
2021.08.08 13:18:22 5: Starting notify loop for CUL433, 1 event(s), first is raw: is00FFF00FFFF0
2021.08.08 13:18:22 5: Wasserzaehler : WaterCalculator Begin_______________________________________________________________________________________________________________________________
2021.08.08 13:18:22 5: Wasserzaehler : WaterCalculator - Notify - Trigger Dev Name                                                : CUL433
2021.08.08 13:18:22 5: End notify loop for CUL433
2021.08.08 13:18:22 5: IT_Set: GetFn(raw): message = is00FFF00FFFF0 Antwort =   raw => is00FFF00FFFF0
2021.08.08 13:18:22 4: ITSet: Answer from CUL433:   raw => is00FFF00FFFF0
2021.08.08 13:18:22 4: WEBadmin: /fhem?cmd.ELRO_2C=set%20ELRO_2C%20off....

Abgesehen davon, dass ich keinen blassen Schimmer habe, warum hier der WaterCalculator benachrichtigt wird (DEF: HAR_Sensoren:COUNTER_C1:.*), zeigt sich auch hier, dass der Code nur einmal per gesendet wird und der CUL433 das auch sauber bestätigt. Woher und warum die Events für BSS_D und ELRO2E entstehen ...?
« Letzte Änderung: 08 August 2021, 13:47:25 von Pfriemler »
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

 

decade-submarginal