Re: [CUL_HM] Probleme mit on/off

Begonnen von Hausautomat, 16 Dezember 2012, 16:30:58

Vorheriges Thema - Nächstes Thema

Hausautomat

                                                         

Irgendwie stelle ich mich heute etwas blöde an.

Der HM-Teil meiner fhem-Installation will nicht mehr auf set on/off
reagieren. Toggle geht (Command accepted: yes, Device schaltet auch).
On-till geht auch, StatusRequest ebenfalls. Beispiel:

2012-12-16_16:21:11 CUL_HM_switch_1859B6_Sw_02 set_toggle
2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 CommandAccepted: yes
2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 deviceMsg: on (to Cuno)
2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 on
2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 RSSI: -55.5
2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 RAWMSG: A0E1D80021859B6F100000102C8003725

Was nicht geht - on/off.
Kein CommandAccepted, nur ein

2012-12-16_16:21:20 CUL_HM_switch_1859B6_Sw_02 set_off

Resend Nr. 2 + 3 finden sich dann im fhem-log natürlich, nur leider
schaltet er nicht. Da kein weiteres logging erfolgt, vermute ich
Software und nicht Hardware - habe den Cuno trotzdem mal rebootet, der
tut aber, wie er soll (Empfang HM und HMS-Emulation für 10 OW-Tempsensoren).

Liegt das irgendwo im CUL_HM? Welche Info ist nötig?

Danke & Gruß
  Jens


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Moin,

habe das gleiche Problem.

Ich hab hier aus Zeitgründen eine Weile nicht mehr so intensiv mitgelesen
und bin daher nicht mehr auf dem Laufenden.

Ich habe heute meine FB und gleichzeitig FHEM auf den neuesten Stand
gebracht. Seitdem lässt sich mein Switch nicht über fhem schalten und ich
bekomme Missing Acks. Dabei war der sonst als einziger immer zu 100 %
zuverlässig.

Hab das Gerät auch mal gelöscht und neu gepairt. Gleiches Ergebnis.

Am Sonntag, 16. Dezember 2012 16:30:58 UTC+1 schrieb Hausautomat:
>
> Irgendwie stelle ich mich heute etwas blöde an.
>
> Der HM-Teil meiner fhem-Installation will nicht mehr auf set on/off
> reagieren. Toggle geht (Command accepted: yes, Device schaltet auch).
> On-till geht auch, StatusRequest ebenfalls. Beispiel:
>
> 2012-12-16_16:21:11 CUL_HM_switch_1859B6_Sw_02 set_toggle
> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 CommandAccepted: yes
> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 deviceMsg: on (to Cuno)
> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 on
> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 RSSI: -55.5
> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 RAWMSG:
> A0E1D80021859B6F100000102C8003725
>
> Was nicht geht - on/off.
> Kein CommandAccepted, nur ein
>
> 2012-12-16_16:21:20 CUL_HM_switch_1859B6_Sw_02 set_off
>
> Resend Nr. 2 + 3 finden sich dann im fhem-log natürlich, nur leider
> schaltet er nicht. Da kein weiteres logging erfolgt, vermute ich
> Software und nicht Hardware - habe den Cuno trotzdem mal rebootet, der
> tut aber, wie er soll (Empfang HM und HMS-Emulation für 10
> OW-Tempsensoren).
>
> Liegt das irgendwo im CUL_HM? Welche Info ist nötig?
>
> Danke & Gruß
>   Jens
>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

fladdy

                                                             

Moin,

bei mir auch mit CUL/Raspi.

Fladdy

Am Sonntag, 16. Dezember 2012 18:12:13 UTC+1 schrieb Carsten:
>
> Moin,
>
> habe das gleiche Problem.
>
> Ich hab hier aus Zeitgründen eine Weile nicht mehr so intensiv mitgelesen
> und bin daher nicht mehr auf dem Laufenden.
>
> Ich habe heute meine FB und gleichzeitig FHEM auf den neuesten Stand
> gebracht. Seitdem lässt sich mein Switch nicht über fhem schalten und ich
> bekomme Missing Acks. Dabei war der sonst als einziger immer zu 100 %
> zuverlässig.
>
> Hab das Gerät auch mal gelöscht und neu gepairt. Gleiches Ergebnis.
>
> Am Sonntag, 16. Dezember 2012 16:30:58 UTC+1 schrieb Hausautomat:
>>
>> Irgendwie stelle ich mich heute etwas blöde an.
>>
>> Der HM-Teil meiner fhem-Installation will nicht mehr auf set on/off
>> reagieren. Toggle geht (Command accepted: yes, Device schaltet auch).
>> On-till geht auch, StatusRequest ebenfalls. Beispiel:
>>
>> 2012-12-16_16:21:11 CUL_HM_switch_1859B6_Sw_02 set_toggle
>> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 CommandAccepted: yes
>> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 deviceMsg: on (to Cuno)
>> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 on
>> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 RSSI: -55.5
>> 2012-12-16_16:21:12 CUL_HM_switch_1859B6_Sw_02 RAWMSG:
>> A0E1D80021859B6F100000102C8003725
>>
>> Was nicht geht - on/off.
>> Kein CommandAccepted, nur ein
>>
>> 2012-12-16_16:21:20 CUL_HM_switch_1859B6_Sw_02 set_off
>>
>> Resend Nr. 2 + 3 finden sich dann im fhem-log natürlich, nur leider
>> schaltet er nicht. Da kein weiteres logging erfolgt, vermute ich
>> Software und nicht Hardware - habe den Cuno trotzdem mal rebootet, der
>> tut aber, wie er soll (Empfang HM und HMS-Emulation für 10
>> OW-Tempsensoren).
>>
>> Liegt das irgendwo im CUL_HM? Welche Info ist nötig?
>>
>> Danke & Gruß
>>   Jens
>>
>>
>>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

C. Zimmermann

                                               

Hab den Fehler gefunden, sollte sich also flott fixen lassen, da ich aber
nur nen svn diff gemacht hab, weiß ich nicht ob das sonst noch irgenwelche
auswirkungen hat. Bei mir läufts aber ;)

in 10_CUL_HM
Zeile 2036:
    CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'02'.$chn.'C8');
ändern zu
    CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'02'.$chn.'C80000');

ebenso
zeile 2038
    CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'02'.$chn.'00');
zu
    CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'02'.$chn.'000000');

Grüße

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Hausautomat

                                                         

Hallo Christoph,

Vielen Dank für den Tipp. Jetzt geht es wieder.
@Martin - es gab aber doch bestimmt einen Grund, das zu ändern?

Gruss
Jens




Christoph Zimmermann schrieb:

>Hab den Fehler gefunden, sollte sich also flott fixen lassen, da ich
>aber
>nur nen svn diff gemacht hab, weiß ich nicht ob das sonst noch
>irgenwelche
>auswirkungen hat. Bei mir läufts aber ;)
>
>in 10_CUL_HM
>Zeile 2036:
>   CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'02'.$chn.'C8');
>ändern zu
>CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'02'.$chn.'C80000');
>
>ebenso
>zeile 2038
>    CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'02'.$chn.'00');
>zu
>CUL_HM_PushCmdStack($hash,'++'.$flag.'11'.$id.$dst.'02'.$chn.'000000');
>
>Grüße

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Am Sonntag, 16. Dezember 2012 19:56:55 UTC+1 schrieb Hausautomat:
>
> Hallo Christoph,
>
> Vielen Dank für den Tipp. Jetzt geht es wieder.
> @Martin - es gab aber doch bestimmt einen Grund, das zu ändern?
>
>
>  Grund war  die ramptime nicht zu uebertragen, da sie eh'0' ist und damit
ein Problem bei Rollos addresieren.

Werde es rückgängig machen

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hallo

ich kämpe auch mit diesem Problem...
Nun habe ich mit update 10_CUL_HM.pm die letzte Version geladen leider
klappt es aber noch immer nicht.
Habe ich was falsch gemacht.

Gruß Manuel


IODev
CUL_HM
 deleteattr
<http://192.168.178.1:8083/fhem?cmd.CUL_HM_switch_1AB7B3=deleteattr%20CUL_HM_switch_1AB7B3%20IODev&detail=CUL_HM_switch_1AB7B3>  
devInfo
040100
 deleteattr
<http://192.168.178.1:8083/fhem?cmd.CUL_HM_switch_1AB7B3=deleteattr%20CUL_HM_switch_1AB7B3%20devInfo&detail=CUL_HM_switch_1AB7B3>  
firmware
1.9
 deleteattr
<http://192.168.178.1:8083/fhem?cmd.CUL_HM_switch_1AB7B3=deleteattr%20CUL_HM_switch_1AB7B3%20firmware&detail=CUL_HM_switch_1AB7B3>  
hmClass
receiver
 deleteattr
<http://192.168.178.1:8083/fhem?cmd.CUL_HM_switch_1AB7B3=deleteattr%20CUL_HM_switch_1AB7B3%20hmClass&detail=CUL_HM_switch_1AB7B3>  
model
HM-LC-SW4-SM
 deleteattr
<http://192.168.178.1:8083/fhem?cmd.CUL_HM_switch_1AB7B3=deleteattr%20CUL_HM_switch_1AB7B3%20model&detail=CUL_HM_switch_1AB7B3>  
room
CUL_HM
 deleteattr
<http://192.168.178.1:8083/fhem?cmd.CUL_HM_switch_1AB7B3=deleteattr%20CUL_HM_switch_1AB7B3%20room&detail=CUL_HM_switch_1AB7B3>  
serialNr
JEQ0143887
 deleteattr
<http://192.168.178.1:8083/fhem?cmd.CUL_HM_switch_1AB7B3=deleteattr%20CUL_HM_switch_1AB7B3%20serialNr&detail=CUL_HM_switch_1AB7B3>  
subType
switch
 deleteattr
<http://192.168.178.1:8083/fhem?cmd.CUL_HM_switch_1AB7B3=deleteattr%20CUL_HM_switch_1AB7B3%20subType&detail=CUL_HM_switch_1AB7B3>
CFGFN

 CUL_HM_MSGCNT
14
 CUL_HM_RAWMSG
RA54F6CAA,0001,010409F4,FF,FFB0,2F80021AB7B34A74CB00
 CUL_HM_RSSI
-80
 CUL_HM_TIME
2012-12-16 21:02:24
 DEF  
1AB7B3
 
 LASTIODev
CUL_HM
 MSGCNT
14
 NAME
CUL_HM_switch_1AB7B3
 NR
924
 STATE
MISSING ACK
 TYPE
CUL_HM
 channel_01
CUL_HM_switch_1AB7B3_Sw_01
 channel_02
CUL_HM_switch_1AB7B3_Sw_02
 channel_03
CUL_HM_switch_1AB7B3_Sw_03
 channel_04
CUL_HM_switch_1AB7B3_Sw_04
 hmPairSerial
JEQ0143887
 lastMsg
No:2F - t:02 s:1AB7B3 d:4A74CB 00
 protCmdDel
2
 protLastRcv
2012-12-16 21:02:23
 protResnd
20 last_at:2012-12-16 21:03:15
 protResndFail
10 last_at:2012-12-16 21:03:16
 protSnd
22 last_at:2012-12-16 21:03:12
 protState
CMDs_done_events:3

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

>
> ich kämpe auch mit diesem Problem...
> Nun habe ich mit update 10_CUL_HM.pm die letzte Version geladen leider
> klappt es aber noch immer nicht.
> Habe ich was falsch gemacht.
>
> es sollte alles beim Alten sein fuer on/off.  - Version 2340.

Es hat vorher funktioniert und jetzt nicht meht?
bitte messages loggen und posten und auch das Kommando. Es sollte auf den
Channel angewendet werden, also z.B. CUL_HM_switch_1AB7B3_Sw_01, das ist
klar?

Gruss
Martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com