Missing Ack problem with HM-LC-SW1-PL2

[HeikkiMeksi]

Hi All!

I try to create some kind of freezig protection system to my summer cottage. (at first stage)
I have now  FHEM5.5 + Rasberry Pi + HM-CFG-USB2 + HM Temp sensors + HM swictches + hm weather station.
After some trail and test period i have managed get system partially working. All sensors are working well and also
HM-LC-SW1-PL2 sends their state to FHEM but i cannot send command successfully to the HM-LC-SW1-PL2 switches.
I don't understand why their refuse to accept any commands. Can anybody say where the problem is?

When i change manually the state of switch to off the FHEM shows following internal info:

Internals:
   DEF        217311
   EVENTS     1
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     1
   NAME       Sw_Keittio
   NR         51
   STATE      off
   TYPE       CUL_HM
   hmusb_MSGCNT 1
   hmusb_RAWMSG E217311,0000,002F7566,FF,FFCD,07841021731100000006010000
   hmusb_RSSI -51
   hmusb_TIME 2013-11-06 20:44:20
   lastMsg    No:07 - t:10 s:217311 d:000000 06010000
   protLastRcv 2013-11-06 20:44:20
   rssi_at_hmusb avg:-51 min:-51 max:-51 lst:-51 cnt:1
   Readings:
     2013-11-06 20:44:20   deviceMsg       off (to broadcast)
     2013-11-06 20:44:20   level           0 %
     2013-11-06 20:44:20   running         -
     2013-11-06 20:44:20   state           off
   Helper:
     mId        00A1
     rxType     1
     Prt:
       sProc      0
       Rspwait:
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmusb:
         avg        -51
         cnt        1
         lst        -51
         max        -51
         min        -51
Attributes:
   .devInfo   010100
   .stc       10
   eventMap   on:on off:off toggle:toggle statusRequest:statusRequest
   expert     2_full
   firmware   1.12
   model      HM-LC-SW1-PL2
   peerIDs   
   room       CUL_HM
   serialNr   KEQ0166342
   subType    switch
   webCmd     toggle:on:off:statusRequest


But if i try to turn state of switch from FHEM side result is following:


Internals:
   .triggerUsed 1
   DEF        217311
   EVENTS     1
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     1
   NAME       Sw_Keittio
   NR         51
   STATE      MISSING ACK
   TYPE       CUL_HM
   hmusb_MSGCNT 1
   hmusb_RAWMSG E217311,0000,002F7566,FF,FFCD,07841021731100000006010000
   hmusb_RSSI -51
   hmusb_TIME 2013-11-06 20:44:20
   lastMsg    No:07 - t:10 s:217311 d:000000 06010000
   protLastRcv 2013-11-06 20:44:20
   protResnd  3 last_at:2013-11-06 20:46:52
   protResndFail 1 last_at:2013-11-06 20:46:58
   protSnd    1 last_at:2013-11-06 20:46:37
   protState  CMDs_done_events:4
   rssi_at_hmusb avg:-51 min:-51 max:-51 lst:-51 cnt:1
   Readings:
     2013-11-06 20:44:20   deviceMsg       off (to broadcast)
     2013-11-06 20:44:20   level           0 %
     2013-11-06 20:44:20   running         -
     2013-11-06 20:46:58   state           MISSING ACK
   Helper:
     burstEvtCnt 4
     mId        00A1
     rxType     1
     Prt:
       sProc      0
       Rspwait:
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmusb:
         avg        -51
         cnt        1
         lst        -51
         max        -51
         min        -51
Attributes:
   .devInfo   010100
   .stc       10
   eventMap   on:on off:off toggle:toggle statusRequest:statusRequest
   expert     2_full
   firmware   1.12
   model      HM-LC-SW1-PL2
   peerIDs   
   room       CUL_HM
   serialNr   KEQ0166342
   subType    switch
   webCmd     toggle:on:off:statusRequest

Here is some logfile information:

2013.11.06 20:54:39.474 1: HMLAN_Parse: hmusb R:R2EC42D3B stat:0008 t:00000000 d:FF r:7FFF     m:02 B112 031B1F 20DA58
2013.11.06 20:54:39.475 1: HMLAN_Parse: hmusb no ACK from 20DA58
2013.11.06 20:54:43.079 1: HMLAN_Send:  hmusb S:S2EC442C9 stat:  00 t:00000000 d:01 r:2EC442C9 m:02 B112 031B1F 20DA58
2013.11.06 20:54:44.990 1: HMLAN_Parse: hmusb R:R2EC442C9 stat:0008 t:00000000 d:FF r:7FFF     m:02 B112 031B1F 20DA58
2013.11.06 20:54:44.991 1: HMLAN_Parse: hmusb no ACK from 20DA58
2013.11.06 20:54:47.844 1: HMLAN_Send:  hmusb S:S2EC45565 stat:  00 t:00000000 d:01 r:2EC45565 m:02 B112 031B1F 20DA58
2013.11.06 20:54:49.746 1: HMLAN_Parse: hmusb R:R2EC45565 stat:0008 t:00000000 d:FF r:7FFF     m:02 B112 031B1F 20DA58
2013.11.06 20:54:49.747 1: HMLAN_Parse: hmusb no ACK from 20DA58
2013.11.06 20:54:51.494 1: HMLAN_Send:  hmusb I:K
2013.11.06 20:54:51.602 1: HMLAN_Parse: hmusb V:03C3 sNo:JEQ0534866 d:1DAF78 O:031B1F t:003917F0 IDcnt:0001
2013.11.06 20:54:51.985 1: HMLAN_Send:  hmusb S:S2EC46592 stat:  00 t:00000000 d:01 r:2EC46592 m:02 B112 031B1F 20DA58
2013.11.06 20:54:56.282 1: HMLAN_Parse: hmusb R:R2EC46592 stat:0008 t:00000000 d:FF r:7FFF     m:02 B112 031B1F 20DA58
2013.11.06 20:54:56.283 1: HMLAN_Parse: hmusb no ACK from 20DA58
2013.11.06 20:54:57.817 1: HMLAN_Send:  hmusb S:S2EC47C5A stat:  00 t:00000000 d:01 r:2EC47C5A m:02 B112 031B1F 20DA58
2013.11.06 20:54:59.737 1: HMLAN_Parse: hmusb R:R2EC47C5A stat:0208 t:00000000 d:FF r:7FFF     m:02 B112 031B1F 20DA58


And here part of my test config:

define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId 031B1F
attr hmusb hmLanQlen 1_min
attr hmusb hmProtocolEvents 3
attr hmusb loglevel 1
attr hmusb wdTimer 25


define Sw_Sauna CUL_HM 217206
attr Sw_Sauna .devInfo 010100
attr Sw_Sauna .stc 10
attr Sw_Sauna expert 1
attr Sw_Sauna firmware 1.12
attr Sw_Sauna model HM-LC-SW1-PL2
attr Sw_Sauna peerIDs
attr Sw_Sauna room CUL_HM
attr Sw_Sauna serialNr KEQ0165680
attr Sw_Sauna subType switch
attr Sw_Sauna webCmd toggle:on:off:statusRequest


Any glue?

Best Regards Heikki

[rudolfkoenig]

Are you sure that pairing the device with FHEM went without problems?

[HeikkiMeksi]

No, i am not sure but i think that it goes well because the autocreate function (?) creates the whole device configuration automatically
during pairng process. How i can check it? 

[martinp876]

Hello Heikki,

logs show that the device simply does not respond to the commands. The last message - btw - shows that HMLAN is in high-load condition, thus short before overload. There are some things odd.

first - is your SW up-to-date? just version 5.5 is not sufficient. Please make sure to run "update" if not already done.

I assume 031B1F is your HMLAN interface.
FHEM sends a burst-wakeup. This is not the type of device that needs/wants that command. Can you let me know, why this happens? Do you send this on purpose or is this system driven?

I would expect the switch does not answer to this message ever.
As this is a burst-start message an it is not answered you will overload HMLAN after 30 attempts.

furthermore, mentioned by Rudi, you need to check whether the device is paired correctly. Therefore read the configuration and check that the PairedTo reading contains the HMId of the HMLAN

Regards,
Martin

[HeikkiMeksi]

Hi!

Thank you about a very fast response. Unfortunately i have not time to do more serious tests until weekend.  But it is clear that i don't  fully understand the role of
HmId. Is it the ID what i can give or is the correct ID found from somewhere?   Readings   Since i don't speak Germany, reading forums with google translator
is little bit slowly  

Second thing,  "FHEM sends a burst-wakeup" is system driven, i actually don't know how to send it.

Best Regards
Heikki

[martinp876]

Heikki,

no problem with your non-existing German. Fortunately the commandref is English.

HMId: is the 3byte address of the device used in all the messaging. It is displayed and transmitted in ascii-hex - thus it is 6 chars ascii. For channels we add the channel-number to the end and thus have an 8-chars ascii string.

The HMId must be unique in the system - and therefore (like MAC addresses) eQ3 "burns " it to each device. It is not changeable.

HMId can be set for the HMLAN (or whatever IO device you use).

Regarding Burst - FHEM knows the capabilities of each device due to the models attribute. If the device is a burst model FHEM will send burst automatically. Special are "conditional burst" devices - devices that support wakeup but can enable burst mode additional.
conditional burst devices are e.g. RT or TC. Generally they wake up periodically (here every 2.5min) and FHEM can communicate. If you need to peer them with window-contacts this is no longer sufficient, RT needs to receive immediately. Then device will enable burst.
You can take advantage in FHEM in the following way
- enable burstRx register (necessary to allow burst at all)
- set attribute burstAcces: FHEM will send each command automatically using burst. This is fast but I would not recommend it
- send command burstXmit - you first issue your commands that then(if you dont want to wait for wakeup) you issue this command. FHEM tries (one time only) to burst-wakeup the device. If it fails FHEM will wait for normal wakeup.

Problems with burst:
HMLAN has a max send capability per one hour. If this is exceeded HMLAN will receive further - but deny any sending.
One burst-wakeup will "cost" the equivalent of 16 other messages. If the device does not answer HMLAN will have 2 retries. 30 failed burst tries already cause an overload!

enabling burst on a device will cost batteries. One reason is, that the receiver needs to be up all the time. Second is, that the device will wakeup with each burst-wakeup, checking who is addressed and fell asleep again.

I hope this give you sufficient insight to FHEM-HM

Regards, Martin

[HeikkiMeksi]

Hi,

Thank you about you advice!  I am learning slowly.... And you are right. There is enough information also in English,
no problem for me.

In a weekend i updates the FHEM and continue my testing. Unfortenately i have still the same missing ack problem.

It was supprise to me that the HmId of devices is not related with their serial number (or ?).
Lucilly the autocreation function was working well and i was able to find include all my currently connected devices to the FHEM.
But what about HmId of master? I mean CUL. I have understood that i can select if freely?  (but not  existing ones)
My CUL is Homemeatic HM-CFG-USB2. Does it have own HmId and is it necessary to use that Hmid somewhere?
Actually I find a ID from messages what i think is address (HmId) of CUL.

About missing ack problem, I have found that it is not actually related to the  HM-LC-SW1-PL2,
it happens with all my units. The protocol of (EQ3//Homematic) is not familar to me but it seems that
readings are working only via broadcast messages (messages to all?) when all the device to device messages fails.   

What i have done wrong or not to done?


I have thinking following possibilities:

1) Something about HmId of HM-CFG-USB2?
   - After all i have not done pairing correctly.
   - if i change HmId the system is still working exactly same way
   - HmSniff program changes HmId what i have give to 000000 

2) Something with Encryption.
   - There is possibility to switch encryption-mode off from HMLAN but i have not found this selection
     found from  "Homemeatic konfigurationsadapter USB Usersoftware"

3) HM-CFG-USB2 does supports only configuration operations not a real messages

4) I have made first pairings with HM "HM USB Usersoftware" in Windows!
    - This comes my mind just when i am writing this.
    - The configuration is stored in HM-CFG-USB2 ?
    - System "Owner" or "permission" stored to to CFG:USB2 is now in my Windows/HM USB configurator not for my Rasberry/Unix/Fhem
    - Do i need to reset my devices or/and CUL to factory defaults?

5) Something else?


BR Heikki


ps. I am quite pleased all ready about my FHEM/Homematic because all the readings a working (autocreation+broadcast messages)
but of course i need to get also the control direction to work in some point of future.

[martinp876]

Hi,

HMId is unique to the device as the serial number. Nevertheless boh are different in format, meaning and usage.

while HMId for all HM device is burned into the device you have to select one for IO devices. For both HMLANor CUL you have to set attribut hmId. You may use any number not already in use in your system.

missing ACK means that FHEM issued a message and expects an answer. This did not come - i.e. the device did not answer at all.
Possible reasons could be that the device is not paired to your IO device (CUL). Each device should be paired to FHEM - precisely to one IO device (you may operate several with different hmIds). Pairing technically means that you tell the device the HMId of its "master" (practically the HMId of the CUL).
Pairing should be clear, I hope. You issue "hmPairForSec 300" on the iodevice and then press "config" on your device. FHEM will to the necessary items. you need to check whether it was successful. Whether FHEM defines all channels and devices is NOR a proof for pairing. you need to check "pairedTo" reading (it is retrieved by getConfig command - should be done automatically if autoReadReg = 4).

Hint: HMInfo is meant to check HM installation in FHEM.
You have to define a single instance
define hm HMinfo
and then you can search all devices (skip channels)
set hm param -d PairedTo
You should see a list of all your physical devices - all need to have the HMId of the IO device

Note: If you change the HMId of your IO device you have to pair all device new - pairing is bound to the HMId!

If you paired the devices with HM PC SW already this is not a problem in first place. You can either use the HMId that was selected by HM-PC-SW in teh attribut hmId or you pair all devices again.

Let me know how it work
Martin

[HeikkiMeksi]

Hi!

I had to thank you about you patience and advises!  System is working now!
My problem was missing pairing, after all!
 
"set hm param -d PairedTo" shows to me that my device list was empty!

So i first removed devices from "my USB-Configurator" in Windows side (this maybe was not necessary)
and after that  i do the pairing procedure again in FHEM/Raspberry side.  And now everything works!

Thank you, now i am free to continue towards future problems!

Best ... Heikki