[HM-Wired] HMW_LC-Sw2_DR - Reading State nicht immer richtig / aktuell

Begonnen von sprudelverduenner, 06 Oktober 2015, 15:25:28

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 2 3 4 Alle
Benutzer-Aktionen

Thorsten Pferdekaemper

#45
10 November 2015, 11:49:17
Hi,
sorry für die späte Antwort. Ich war im Urlaub und habe jetzt wenig Zeit. Das Log durchzugehen braucht ja schon etwas Muße. Es wäre auch nicht schlecht gewesen, wenn Du mir die Zeit (Uhrzeit) der Aktionen genannt hättest. Kannst Du das noch?
Gruß,
   Thorsten
FUIP

sprudelverduenner

#46
10 November 2015, 17:40:42
Moin moin,

also insgesamt sind in dem LOG nur dIe 2 angesprochenen Aktionen drinne.

Ich kann mir natürlich gerne den LOG noch einmal vornehmen und alle anderen Sachen, die nichts damit zu tun haben, löschen, so dass der LOG kompakter wird ...

LG Sprudelverduenner
FHEM @ RaspberryPi 3, HMLAN, HMUART + HMRS485, Homematic, ESPEasy @ Sonoff / Shelly / ESP8266, ZigBee @ CC2531
Echo Dot, Dreambox, Yamaha MusicCast, Logitech Hub, LW-12, LD382
FRITZ!Box 7590 AX, Mesh @ FRITZ!Repeater 2400, FRITZ!Fon, iPhone 13, iPad Air 5, AppleWatch 8

Thorsten Pferdekaemper

#47
10 November 2015, 22:07:44
Hi,
das ganze sieht so aus, als ob Du FHEM gerade gestartet hast und erst einmal die ganze Konfiguration von den Devices gelesen wird. Dadurch steht erst einmal ziemlich viel Kram im Log und außerdem kann es durchaus sein, dass die Kommunikation zwischen FHEM und den Devices noch nicht so richtig klappt. Eigentlich sollte das nicht so sein, aber es ist ziemlich schwierig nachzuvollziehen.
Könntest Du mal folgendes machen:
1. Sicherstellen, dass FHEM schon ein paar Minuten läuft und in allen HMW-Devices das Reading (nicht das Internal!) configStatus auf OK steht.
2. Dann das Attribut verbose im Device HMRS485 auf 5 setzen. (Nicht verbose in global.)
3. Dann versuchen, die entsprechenden Logs zu erzeugen, d.h. einmal mit der richtigen Funktion und einmal wo es nicht klappt.
Gruß,
    Thorsten
FUIP

sprudelverduenner

#48
15 November 2015, 15:20:38
Ich hoffe hier ist jetzt etwas verwertbares für Dich dabei....

1. Fall: flur.eltako.1_03 geht an / flur.eltako.1_04 bleibt aus [beides sollte an gehen]

Code Auswählen
2015.11.15 15:09:38 1: Including fhem.cfg
2015.11.15 15:09:38 3: telnetPort: port 7072 opened
2015.11.15 15:09:38 3: WEB: port 8083 opened
2015.11.15 15:09:38 3: WEBphone: port 8084 opened
2015.11.15 15:09:38 3: WEBtablet: port 8085 opened
2015.11.15 15:09:40 2: eventTypes: loaded 3770 events from ./log/eventTypes.log
2015.11.15 15:09:40 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.11.15 15:09:40 3: Opening HMLAN1 device 192.168.1.51:1000
2015.11.15 15:09:40 3: HMLAN1 device opened
2015.11.15 15:09:40 1: HMLAN_Parse: HMLAN1 new condition init
2015.11.15 15:09:41 1: Including /opt/fhem/FHEM/sub_externe-geraete.cfg
2015.11.15 15:09:41 2: FRITZBOX fritz.box: TR064_Init.4099 The device 'undefined' doesn't have a TR-064 API or TR-064 is switched off.
2015.11.15 15:09:41 3: Opening fritz.box.callmonitor device 192.168.1.10:1012
2015.11.15 15:09:41 3: fritz.box.callmonitor device opened
2015.11.15 15:09:44 1: Including /opt/fhem/FHEM/sub_fenster.cfg
2015.11.15 15:09:44 1: Including /opt/fhem/FHEM/sub_heizung.cfg
2015.11.15 15:09:45 1: Including /opt/fhem/FHEM/sub_licht.cfg
2015.11.15 15:09:47 1: Including /opt/fhem/FHEM/sub_rollade.cfg
2015.11.15 15:09:48 1: Including /opt/fhem/FHEM/sub_schalter.cfg
2015.11.15 15:09:49 2: HMRS485: Assigned 0000AE4F as flur.eltako.1
2015.11.15 15:09:49 3: HMRS485: Warte auf Initialisierung Gateway
2015.11.15 15:09:49 2: HMRS485: Assigned 0000AE44 as flur.eltako.2
2015.11.15 15:09:49 3: HMRS485: Warte auf Initialisierung Gateway
2015.11.15 15:09:49 1: Including ./log/fhem.save
2015.11.15 15:09:54 3: Opening HMRS485 device 192.168.1.52:1000
2015.11.15 15:09:54 3: HMRS485 device opened
2015.11.15 15:09:54 3: HMRS485: connected to device 192.168.1.52:1000
2015.11.15 15:09:55 3: HMRS485: Initialisierung von Modul 0000AE4F
2015.11.15 15:09:55 3: HMRS485: Initialisierung von Modul 0000AE44
2015.11.15 15:09:55 1: HMLAN_Parse: HMLAN1 new condition ok
2015.11.15 15:09:55 3: HMRS485: Lan Device Information
2015.11.15 15:09:55 3: HMRS485: Protocol-Version: 01
2015.11.15 15:09:55 3: HMRS485: Interface-Type: eQ3-HMW-LGW
2015.11.15 15:09:55 3: HMRS485: Firmware-Version: 1.0.4
2015.11.15 15:09:55 3: HMRS485: Serial-Number: LEQ0636924
2015.11.15 15:09:55 3: HMRS485: Initialize the interface
2015.11.15 15:09:56 3: Device aussen.tuer.motion added to ActionDetector with 000:10 time
2015.11.15 15:09:56 3: Device bad.fenster added to ActionDetector with 028:00 time
2015.11.15 15:09:56 3: Device bad.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:56 3: Device buegelz.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:56 3: Device buero.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:57 3: Device buero.tuer added to ActionDetector with 028:00 time
2015.11.15 15:09:57 3: Device flur.fenster.rechts added to ActionDetector with 028:00 time
2015.11.15 15:09:57 3: Device flur.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:57 3: Device gaestez.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:58 3: Device kueche.fenster added to ActionDetector with 028:00 time
2015.11.15 15:09:58 3: Device kueche.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:58 3: Device schlafz.fenster added to ActionDetector with 028:00 time
2015.11.15 15:09:58 3: Device schlafz.heizung added to ActionDetector with 000:10 time
2015.11.15 15:09:59 3: Device wohnz.fenster.links added to ActionDetector with 028:00 time
2015.11.15 15:09:59 3: Device wohnz.heizung.links added to ActionDetector with 000:10 time
2015.11.15 15:09:59 3: Device wohnz.heizung.rechts added to ActionDetector with 000:10 time
2015.11.15 15:09:59 3: Opening Sonos device localhost:4711
2015.11.15 15:09:59 3: Sonos device opened
2015.11.15 15:10:00 3: flur.eltako.1: Request config for device 0000AE4F
2015.11.15 15:10:00 3: flur.eltako.1: Lese Eeprom 0000AE4F
2015.11.15 15:10:00 3: flur.eltako.2: Request config for device 0000AE44
2015.11.15 15:10:00 3: flur.eltako.2: Lese Eeprom 0000AE44
2015.11.15 15:10:00 3: CUL_HM set aussen.tuer.lampe statusRequest
2015.11.15 15:10:01 3: CUL_HM set bad.rollade.fenster statusRequest
2015.11.15 15:10:03 3: CUL_HM set buero.rollade.fenster statusRequest
2015.11.15 15:10:04 3: CUL_HM set buero.rollade.tuer statusRequest
2015.11.15 15:10:05 3: CUL_HM set flur.eingang.licht statusRequest
2015.11.15 15:10:06 3: CUL_HM set flur.rollade.links statusRequest
2015.11.15 15:10:07 3: CUL_HM set flur.rollade.rechts statusRequest
2015.11.15 15:10:08 3: CUL_HM set gaestez.rollade.fenster statusRequest
2015.11.15 15:10:10 3: CUL_HM set kueche.licht statusRequest
2015.11.15 15:10:10 3: HMRS485: HM485_QueueStepFailed Call step
2015.11.15 15:10:10 3: flur.eltako.2: RESPONSE TIMEOUT for 0000AE44
2015.11.15 15:10:12 3: CUL_HM set kueche.rollade.fenster statusRequest
2015.11.15 15:10:12 3: FRITZBOX fritz.box: Readout_Process.1556 TR-064 is switched on
2015.11.15 15:10:13 3: CUL_HM set schlafz.licht statusRequest
2015.11.15 15:10:14 3: CUL_HM set schlafz.rollade.fenster statusRequest
2015.11.15 15:10:15 3: CUL_HM set vorrat.rollade.fenster statusRequest
2015.11.15 15:10:15 3: HMRS485: Initialisierung von Modul 0000AE44
2015.11.15 15:10:16 3: flur.eltako.2: Request config for device 0000AE44
2015.11.15 15:10:16 3: flur.eltako.2: Lese Eeprom 0000AE44
2015.11.15 15:10:17 3: CUL_HM set wohnz.dimmer.led12 statusRequest
2015.11.15 15:10:18 3: CUL_HM set wohnz.dimmer.led34 statusRequest
2015.11.15 15:10:19 3: CUL_HM set wohnz.rollade.links statusRequest
2015.11.15 15:10:20 3: CUL_HM set wohnz.rollade.rechts statusRequest
2015.11.15 15:10:24 3: CUL_HM set hm_fernbedienung getConfig
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
2015.11.15 15:11:40 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state_flags value1 = 4
2015.11.15 15:11:40 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 1
2015.11.15 15:11:40 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state value1 = 200
2015.11.15 15:11:40 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 1
2015.11.15 15:11:40 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 03 msgData = 6902C840 actionType = frame


2. Fall: flur.eltako.1_03 bleibt aus / flur.eltako.1_04 geht an [beides sollte an gehen]

Code Auswählen
2015.11.15 15:13:01 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state_flags value1 = 0
2015.11.15 15:13:01 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:01 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state value1 = 0
2015.11.15 15:13:01 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:01 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 03 msgData = 69020000 actionType = frame
2015.11.15 15:13:06 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:06 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:06 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0000DF actionType = frame
2015.11.15 15:13:06 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:06 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:06 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0000DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0000DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0000DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0002DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 55
2015.11.15 15:13:07 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 55
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 01 msgData = 4B0003DF actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F No channel
2015.11.15 15:13:08 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state_flags value1 = 0
2015.11.15 15:13:08 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:08 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state value1 = 200
2015.11.15 15:13:08 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 1
2015.11.15 15:13:08 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 04 msgData = 6903C800 actionType = frame
2015.11.15 15:13:19 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:19 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:19 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0100D3 actionType = frame
2015.11.15 15:13:19 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:19 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:19 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0100D3 actionType = frame
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:20 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0100D3 actionType = frame
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:20 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0102D3 actionType = frame
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = counter value1 = 52
2015.11.15 15:13:20 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 52
2015.11.15 15:13:20 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 02 msgData = 4B0103D3 actionType = frame
2015.11.15 15:13:20 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F No channel
2015.11.15 15:13:21 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state_flags value1 = 0
2015.11.15 15:13:21 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:21 5: flur.eltako.1: Device:convertFrameDataToValue: deviceKey = HMW_LC_SW2_DR valId = state value1 = 0
2015.11.15 15:13:21 5: flur.eltako.1: Device:convertFrameDataToValue: value2 = 0
2015.11.15 15:13:21 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 04 msgData = 69030000 actionType = frame


Lieben Gruß

Sprudelverduenner
FHEM @ RaspberryPi 3, HMLAN, HMUART + HMRS485, Homematic, ESPEasy @ Sonoff / Shelly / ESP8266, ZigBee @ CC2531
Echo Dot, Dreambox, Yamaha MusicCast, Logitech Hub, LW-12, LD382
FRITZ!Box 7590 AX, Mesh @ FRITZ!Repeater 2400, FRITZ!Fon, iPhone 13, iPad Air 5, AppleWatch 8

Thorsten Pferdekaemper

#49
16 November 2015, 18:24:26
Zitat von: sprudelverduenner am 15 November 2015, 15:20:38
Ich hoffe hier ist jetzt etwas verwertbares für Dich dabei....
Der erste Ausschnitt sieht zwar immer noch so aus als ob FHEM gerade hochfaehrt, aber jetzt kann man tatsaechlich ein bisschen was sehen. Allerdings habe ich gerade keinen Zugriff auf meinen ganzen FHEM-Kram und muss das alles aus dem Kopf machen.

Zitat
1. Fall: flur.eltako.1_03 geht an / flur.eltako.1_04 bleibt aus [beides sollte an gehen]

Code Auswählen

2015.11.15 15:09:49 2: HMRS485: Assigned 0000AE4F as flur.eltako.1
2015.11.15 15:09:49 2: HMRS485: Assigned 0000AE44 as flur.eltako.2
2015.11.15 15:09:54 3: HMRS485: connected to device 192.168.1.52:1000
2015.11.15 15:09:55 3: HMRS485: Initialisierung von Modul 0000AE4F
2015.11.15 15:09:55 3: HMRS485: Initialisierung von Modul 0000AE44
2015.11.15 15:10:00 3: flur.eltako.1: Request config for device 0000AE4F
2015.11.15 15:10:00 3: flur.eltako.1: Lese Eeprom 0000AE4F
2015.11.15 15:10:00 3: flur.eltako.2: Request config for device 0000AE44
2015.11.15 15:10:00 3: flur.eltako.2: Lese Eeprom 0000AE44
2015.11.15 15:10:10 3: HMRS485: HM485_QueueStepFailed Call step
2015.11.15 15:10:10 3: flur.eltako.2: RESPONSE TIMEOUT for 0000AE44

Da scheint es irgend ein Problem auf Deinem Bus zu geben. Vielleicht reagiert Dein eQ3-HMW-LGW aber auch nicht so, wie ich das vermute. Das waere aber etwas schade, weil dann waere der FHEM-Daemon sogar besser als der HM-Original-Kram.

Zitat
Code Auswählen

2015.11.15 15:10:16 3: flur.eltako.2: Request config for device 0000AE44
2015.11.15 15:10:16 3: flur.eltako.2: Lese Eeprom 0000AE44
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F
2015.11.15 15:11:10 5: flur.eltako.1: Device:getRawEEpromData hmwId = 0000AE4F

Kann es sein, dass Du verbose fuer flur.eltako.2 explizit auf 3 sitzen hast? Ich sehe naemlich keine einzige Level-5 Message fuer flur.eltako.2. Koenntest Du das mal pruefen und das ganze ggf. nochmal machen?

Zitat
Code Auswählen

2015.11.15 15:11:40 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 03 msgData = 6902C840 actionType = frame

Das ist die einzige Message, die darauf hindeutet, dass der flur.eltako.1 seinen Zustand sendet. Er teilt da gerade mit, dass Kanal 02 (also nach aussen Kanal 3) auf "on" gesetzt wurde. Zum Kanal 4 steht hier tatsaechlich nichts.
Ist das wirklich alles, oder kommt danach noch was im Log?

Zitat
2. Fall: flur.eltako.1_03 bleibt aus / flur.eltako.1_04 geht an [beides sollte an gehen]

Code Auswählen

2015.11.15 15:13:01 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 03 msgData = 69020000 actionType = frame
2015.11.15 15:13:07 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F No channel
2015.11.15 15:13:08 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 04 msgData = 6903C800 actionType = frame
2015.11.15 15:13:21 5: flur.eltako.1: HM485_ProcessChannelState: hmwId = 0000AE4F Channel = 04 msgData = 69030000 actionType = frame

Das heisst uebersetzt: Kanal 3 wird auf "off" gesetzt, dann Kanal 4 auf "on", dann Kanal 4 wieder auf "off". Das ist aber nicht ganz das, was Du gesagt hast. Ausserdem wundert mich das mit dem "No channel" zwischendurch.

Tja, was sollen wir jetzt damit machen?
Also erst einmal erinnere ich mich daran, dass wenn ich bei einem meiner HMW-Devices zwei Ausgaenge schnell hintereinander schalte, dass dann die "logging"-Message nicht fuer beide kam. Das ist dann ein Problem der HMW-Devices und FHEM koennte da auch nichts machen. Das muesste ich mir mal daheim anschauen, was aber fruehestens naechste Woche geht. Wenn das wirklich der Fall ist, dann koennte man noch etwas mit notify und get machen.
Ansonsten koennte ich Dir anbieten, dass wir mal eine Session ueber Skype machen. (Ich nehme nicht an, dass Du in meiner Nachbarschaft wohnst.) Dann koennten wir etwas direkter kommunizieren und ich wuerde auch direkt sehen, welche Aktion genau was ausloest. Wenn Du das willst, dann schreib' mir mal eine PM mit Deiner e-mail, Deinem Skype-Namen und einem Terminvorschlag fuer naechste Woche.

Gruss,
   Thorsten




FUIP

sprudelverduenner

#50
17 November 2015, 09:25:12
Moin Thorsten,

das ist in der Tat der komplette LOG, den ich nur in die 2 unterschiedlichen Fehlerbilder getrennt habe.
Aber Du hast recht, ich Dussel habe nur vom 1. Aktor den Verbose geändert.
Da ich das LOG-File generell auskommentiert habe ist am Anfang - nach der Aktivierung des LOGs - dann noch etwas mehr zu lesen.

Sehr gerne würde ich auf Dein Angebot einer Skype Session zurück kommen. Teamviewer wäre bei mir auch am Start. Alles Weitere kommt dann per PM.

Vielen Dank vorab.

LG Sprudelverduenner
FHEM @ RaspberryPi 3, HMLAN, HMUART + HMRS485, Homematic, ESPEasy @ Sonoff / Shelly / ESP8266, ZigBee @ CC2531
Echo Dot, Dreambox, Yamaha MusicCast, Logitech Hub, LW-12, LD382
FRITZ!Box 7590 AX, Mesh @ FRITZ!Repeater 2400, FRITZ!Fon, iPhone 13, iPad Air 5, AppleWatch 8

Thorsten Pferdekaemper

#51
24 November 2015, 22:53:37
Hi,

ich habe jetzt auch mal ein bisschen damit herumgespielt. Tatsächlich kommt auch nur ein Kanal an, wenn man die zwei Knöpfe oben auf dem Teil gleichzeitig drückt. Dagegen kommen beide an, wenn man die Knöpfe schnell hintereinander drückt. Das finde ich zwar etwas seltsam, aber ich hab's bestimmt 100 mal ausprobiert.
Mit dieser Erkenntnis habe ich dann auch herausgefunden, dass folgender eigentlich ganz einfacher Workaround funktioniert.
Mach mal im Kanal "get ... peersettings <peer>". Als <peer> wählst Du den zweiten Aktor am problematischen Device aus.
Dort setzt Du dann "short_ondelay_time" und "short_offdelay_time" jeweils auf 0.20 s. (0.10 reicht nicht, das habe ich ausprobiert.)
Dann unten "Save Settings" drücken oder einfach <return>.
Jetzt geht die zweite Lampe 0.2s nach der ersten an und die Rückmeldungen kommen beide.

So, das zur Theorie. Blöderweise habe ich in einer der letzten Änderungen einen Fehler gemacht, so dass Kanal- und Verknüpfungsparameter unter Umständen nicht änderbar sind. Sollte das bei Dir der Fall sein, dann brauchst Du die aktuelle dev-Version. Siehe auch hier:
http://forum.fhem.de/index.php/topic,10607.msg364510.html#msg364510

Gruß,
   Thorsten
FUIP

sprudelverduenner

#52
26 November 2015, 15:25:50
Hallo Thorsten,

vielen Dank für Deine Rückmeldung.

Ich habe das gestern mal auf die Schnelle getestet - Dein Tipp sieht ganz gut aus.
Ich habe die Verzögerung bei mir auf 0,30 hochgestellt - darunter kam es bei mir noch zu falschen STATEs.
Seit dem hatte ich bei meinen ersten Tests zuverlässige Ergebnisse.

Eine Sache ist mir noch aufgefallen:
Ich arbeite seit Längerem mit einem DOIF, das die Leuchte 3 ausschaltet, wenn Leuchte 1,2 und 4 aus sind.
Bis vor ca. 2 Monaten funktionierte dies auch. Ich habe seitdem - bis auf deine Firmwares - nichts verändert.
Manchmal geht die Leuchte 3 aber sofort nach dem Einschalten der Leuchten 1 und 2 direkt wieder aus.

Gestern ist mir wahrscheinlich auch aufgefallen warum:
Der STATE beider Ausgänge ist ON aber das Reading des State in der DOIF ist off.
Kann das sein- oder bin ich auf einer falschen Fährte ? Könntest Du Dir das bitte einmal anschauen ??

Lieben Gruß
Sprudelverduenner


FHEM @ RaspberryPi 3, HMLAN, HMUART + HMRS485, Homematic, ESPEasy @ Sonoff / Shelly / ESP8266, ZigBee @ CC2531
Echo Dot, Dreambox, Yamaha MusicCast, Logitech Hub, LW-12, LD382
FRITZ!Box 7590 AX, Mesh @ FRITZ!Repeater 2400, FRITZ!Fon, iPhone 13, iPad Air 5, AppleWatch 8

Thorsten Pferdekaemper

#53
26 November 2015, 16:14:34
Hi,
mit dem DOIF kenne ich micht nicht aus. Mir ist das Teil etwas suspekt und ich verwende es nicht.
Da müsstest Du vielleicht mal einen anderen Thread aufmachen, so dass sich das mal jemand anschaut, der sich mit DOIF auskennt.
Gruß,
   Thorsten
FUIP

sprudelverduenner

#54
26 November 2015, 16:29:38
OK, dass heisst die dort erscheinenden Readings von dem STATE der Wired Komponente hat nix mit Deiner Programmierung zu tun ... !?

Ich werde das mal mit 2-3 notifys aufbauen und testen.
Ich denke ich bin jetzt nicht mehr weit von einer vernünftig funktionierenden Lösung entfernt ;-):

Gruß Sprudelverduenner
FHEM @ RaspberryPi 3, HMLAN, HMUART + HMRS485, Homematic, ESPEasy @ Sonoff / Shelly / ESP8266, ZigBee @ CC2531
Echo Dot, Dreambox, Yamaha MusicCast, Logitech Hub, LW-12, LD382
FRITZ!Box 7590 AX, Mesh @ FRITZ!Repeater 2400, FRITZ!Fon, iPhone 13, iPad Air 5, AppleWatch 8

Thorsten Pferdekaemper

#55
26 November 2015, 19:16:47
Zitat von: sprudelverduenner am 26 November 2015, 16:29:38
OK, dass heisst die dort erscheinenden Readings von dem STATE der Wired Komponente hat nix mit Deiner Programmierung zu tun ... !?
Naja, zumindest nicht direkt. Ich weiß nicht, wie das DOIF auf Readings oder anderes zugreift. (Außerdem: Auf STATE greift es hoffentlich gar nicht zu, das ist nämlich ein Internal. Es müsste das Reading state sein.)
Ich wundere mich auch darüber, dass es im DOIF überhaupt ein Reading on/off gibt. Ist ein DOIF nicht nur ein Helper-Modul? Oder setzt Du den Status (also das Reading state) im DOIF selbst?
Eigentlich wollte ich mich mit dem DOIF nicht auseinandersetzen, aber Du kannst es ja mal hier posten. Vielleicht fällt mir was auf.
Gruß,
   Thorsten
FUIP
Drucken
Nach oben Seiten 1 2 3 4 Alle
Benutzer-Aktionen