HM-LGW and "triggering" smoke detectors

English Forums Hardware
#1

I’m playing around with one of the “new” HM-LAN-Gateways. Almost everything seems to be working ok. The one thing that does not work any more is triggering my smoke detectors. I use the smoke detectors as some sort of alarm system and neither “Smoke Detected” nor “Installation Test” works using the HM-LGW.

The errror message in homegear.err is: HM-LGW “LGW”: Error: Can’t send packet, because sender address is not mine: 0B1F9440160B33FD09F70024.

160B33 is the address of my first smoke detector and the team
FD09F7 is the address of my homegear central.

So it really looks like source and destination is reversed. But this has worked before when I was not using the HM-LAN-Gateway

Is this something I have to live with or is this something fixable?

#2

Hey Wirrkopf,

you can’t enable your smoke detectors with the LAN-Gateway or HM-CFG-LAN, because the sender address differs from the central’s address. As the sender address of the LAN-Gateway and HM-CFG-LAN is one fixed address, sending the required packets is not possible.

But as you have a COC there is no problem. Just use the RPC function “setInterface” to set the interface of the smoke detectors to your COC and it should work again. I would prefer the COC to the HM-LGW anyway, because the HM-LGW crashes sometimes, when a lot of devices are paired to it (maybe 20 or 30+).

Cheers,

Sathya

#3

I wanted to use the LGW, because of some range issues I have with my COC/CUL. An awesome thing would be, if I could set up another raspberry pi running some sort of remote homegear on my top floor instead of the LGW or CUNO devices… Any thoughts on this?

I tried to use setInterface using this snippet:

#!/usr/bin/env php
<?php
if(function_exists("hg_invoke"))
{
/**** Use built-in script engine ****/
print_r(hg_invoke("setInterface", 25, "CUL"));
}
?>

25 is the “Team_Master”. I also used the 0x400000whatever (and the decimal representation of this hex value) ID for the team, but the “LGW: Cannot send because…:” still appears. Do I have to set the Interface on ALL smoke detectors or do I have to do something else for the setting to work?

#4

while trying to “setinterface” on the team, I get:

Warning: hg_invoke(): RPC error (Code -104): Can't set physical interface, because ROAMING is enabled. Please disable ROAMING to manually select the interface.

but there is no way to disable ROAMING on the team. at least not using the .net lib. I will try to do this using the php engine as well.

#5

here’s my script:

[code]#(!/usr/bin/env php

<?php if(function_exists("hg_invoke")) { /**** Use built-in script engine ****/ print_r(hg_set_value(0x40000019, 0, "ROAMING", false)); print_r(hg_invoke("setInterface", 0x40000019, "CUL")); } ?>[/code]

and here is the result:

[code]01/05/15 10:13:44.129 RPC Server (Port 2001): Info: RPC Method called: setValue Parameters:
(Integer) 1073741849
(Integer) 0
(String) ROAMING
(Boolean) 0
01/05/15 10:13:44.129 Script output:

01/05/15 10:13:44.129 RPC Server (Port 2001): Info: RPC Method called: setInterface Parameters:
(Integer) 1073741849
(String) CUL
01/05/15 10:13:44.129 Script output: Warning: hg_invoke(): RPC error (Code -104): Can’t set physical interface, because ROAMING is enabled. Please disable ROAMING to manually select the interface.[/code]

it seems to me that there’s something wrong with the ROAMING/setInterface for a SD team.

#6

Hey Wirrkopf,

there were indeed two issues [1]:

[ol]
[li] The team interface was always set to the default interface on startup[/li]
[li] The check, if ROAMING is enabled indeed had an error causing setInterface to fail[/li][/ol]

Both issues are fixed now and will be in the next nightly (0.5.20-72). ROAMING is not settable for the team, as the team is a virtual device. The interface of the team will always be set to the interface of peer 25 on startup now (as team variables are not saved). So the easiest is to change the interface of that peer. All other smoke detectors can keep their interface.

It’s planned :wink:. The CUNO already is supported. But I don’t recommend using it, as the timing is horrible and the bidirectional communication often fails.

I hope this fixes the problem?

Regards,

Sathya

[1] https://github.com/Homegear/Homegear/issues/146

#7

Thanks, Sathya.

I had quick and dirty commented out the “problematic” line of code and got it to work here. Right now my machine is doing a new git pull, make to test the changes you have done.

I don’t want to use the CUN0 because of the problems you mentioned. My idea would be to spread some RPI/COC combinations throughout my house and have them all run “homegear-remote” and one machine in my basement runs the homegear-master and the openhab setup… If only AES would be possible with the COC …

As long as there is no homegear-remote I will keep the LGW because it looks like it is doing it’s job and the wireless range is really good compared to the old HM-CFG-LANs

#8

Hi Sathya,

from my past experiences with fhem and the HM-CFG-LAN I knew that I could trigger the smoke detectors using the HM-CFG-LAN.

I have commented out the following lines of code:

/* if(bidCoSPacket->senderAddress() != _myAddress) { _out.printError("Error: Can't send packet, because sender address (" + BaseLib::HelperFunctions::getHexString(bidCoSPacket->senderAddress(), 6) + ") is not mine (" + BaseLib::HelperFunctions::getHexString(_myAddress, 6) + "): " + bidCoSPacket->hexString()); return; } */

from hm-cfg-lan.cpp, recompiled the module and restarted homegear.

I have change the Interface for the smoke detector team to my HM-CFG-LAN in my basement and tried to trigger the installation test.

Works without any issues. From this test at least the HM-CFG-LAN can send packets with a sender address != myAddress.

Don’t know if this would make you change the hm-cfg-lan.cpp file or not. If not, I will need to start my own “fork” :slight_smile:

I will try the same using my HM-LGW and report back.

#9

Same result with the HM-LGW.

I have commented out the part inside HM-LGW.cpp which compares sender address with myaddress and I can use the HM-LGW to trigger my smoke detectors.

#10

Hey,

that’s really cool :smiley:! Actually I’ve probably never tested it, because you have to set the HM-CFG-LAN address in the init sequence. That’s why I probably assumed the sender address is fixed (or maybe I did test it - I can’t really remember). Could you send me the log excerpt of triggering the smoke detector? If it looks ok, I will change the source code :wink:.

Cheers,

Sathya

#11

Test using HM-CFG-LAN as Interface:

01/16/15 11:40:14.166 RPC Server (Port 2001): Info: Connection from 192.168.1.116:49191 accepted. Client number: 64 01/16/15 11:40:14.171 RPC Server (Port 2001): Info: Client number 64 is calling RPC method: setValue Parameters: (String) *IEQ0084244:1 (String) INSTALL_TEST (Boolean) 1 01/16/15 11:40:14.183 RPC Server (Port 2001): Info: Connection to client number 64 closed (3). 01/16/15 11:40:14.184 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "HMK": Info: Sending (HMK): 0B539440160B33FD09F7003F 01/16/15 11:40:14.599 HomeMatic BidCoS packet received (LGW, RSSI: 0x4B): 0B539440160B33FD09F7003F 01/16/15 11:40:14.784 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "HMK": Info: Sending (HMK): 0B549440160B33FD09F7003F 01/16/15 11:40:15.219 HomeMatic BidCoS packet received (LGW, RSSI: 0x4B): 0B549440160B33FD09F7003F 01/16/15 11:40:15.384 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "HMK": Info: Sending (HMK): 0B559440160B33FD09F7003F 01/16/15 11:40:15.838 HomeMatic BidCoS packet received (LGW, RSSI: 0x4B): 0B559440160B33FD09F7003F 01/16/15 11:40:15.984 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "HMK": Info: Sending (HMK): 0B569440160B33FD09F7003F 01/16/15 11:40:16.459 HomeMatic BidCoS packet received (LGW, RSSI: 0x4B): 0B569440160B33FD09F7003F 01/16/15 11:40:16.585 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "HMK": Info: Sending (HMK): 0B579440160B33FD09F7003F 01/16/15 11:40:17.078 HomeMatic BidCoS packet received (LGW, RSSI: 0x4B): 0B579440160B33FD09F7003F 01/16/15 11:40:17.186 Module HomeMatic BidCoS: LAN-Konfigurationsadapter "HMK": Info: Sending (HMK): 0B589440160B33FD09F7003F 01/16/15 11:40:17.698 HomeMatic BidCoS packet received (LGW, RSSI: 0x4B): 0B589440160B33FD09F7003F

Test using HM-LGW as interface:

01/16/15 11:48:32.864 RPC Server (Port 2001): Info: Connection from 192.168.1.116:49340 accepted. Client number: 15 01/16/15 11:48:32.876 RPC Server (Port 2001): Info: Client number 15 is calling RPC method: setValue Parameters: (String) *IEQ0084244:1 (String) INSTALL_TEST (Boolean) 1 01/16/15 11:48:32.882 RPC Server (Port 2001): Info: Connection to client number 15 closed (3). 01/16/15 11:48:32.883 Module HomeMatic BidCoS: HM-LGW "LGW": Info: Sending (LGW): 0B5A9440160B33FD09F70040 01/16/15 11:48:33.297 HomeMatic BidCoS packet received (HMK, RSSI: 0x4B): 0B5A9440160B33FD09F70040 01/16/15 11:48:33.301 HomeMatic BidCoS packet received (HMD, RSSI: 0x5B): 0B5A9440160B33FD09F70040 01/16/15 11:48:33.484 Module HomeMatic BidCoS: HM-LGW "LGW": Info: Sending (LGW): 0B5B9440160B33FD09F70040 01/16/15 11:48:33.896 HomeMatic BidCoS packet received (HMD, RSSI: 0x61): 0B5B9440160B33FD09F70040 01/16/15 11:48:33.898 HomeMatic BidCoS packet received (HMK, RSSI: 0x4B): 0B5B9440160B33FD09F70040 01/16/15 11:48:34.083 Module HomeMatic BidCoS: HM-LGW "LGW": Info: Sending (LGW): 0B5C9440160B33FD09F70040 01/16/15 11:48:34.495 HomeMatic BidCoS packet received (HMD, RSSI: 0x61): 0B5C9440160B33FD09F70040 01/16/15 11:48:34.506 HomeMatic BidCoS packet received (HMK, RSSI: 0x4E): 0B5C9440160B33FD09F70040 01/16/15 11:48:34.684 Module HomeMatic BidCoS: HM-LGW "LGW": Info: Sending (LGW): 0B5D9440160B33FD09F70040 01/16/15 11:48:35.097 HomeMatic BidCoS packet received (HMK, RSSI: 0x4C): 0B5D9440160B33FD09F70040 01/16/15 11:48:35.285 Module HomeMatic BidCoS: HM-LGW "LGW": Info: Sending (LGW): 0B5E9440160B33FD09F70040 01/16/15 11:48:35.698 HomeMatic BidCoS packet received (HMK, RSSI: 0x4A): 0B5E9440160B33FD09F70040 01/16/15 11:48:35.701 HomeMatic BidCoS packet received (HMD, RSSI: 0x5A): 0B5E9440160B33FD09F70040

Do you need more lines of the log or is this sufficient?

#12

Quelltextzeilen sind raus :wink:. Echt cool, dass du das herausgefunden hast!!!

Nachtrag: https://github.com/Homegear/Homegear/issues/165

#13

If we are talking about “triggering” the smoke detector, does that mean that the siren can be enabled on demand?

Personally I am looking for an indoor siren that should be used in case an alarm was triggered (e.g. by a window contact). Thus it would be awesome if the smoke detectors can be used as indoor siren without any hardware modifications…

#14

Yes, you can enable the siren on demand.

#15

That’s pretty useful. I really hope that the successor (the HM-SEC-SD-2) will be able to enable the siren on demand as well. Since I’ve read a lot about various issues with the current version I am still waiting for the release date of the successor model.

#16

I have 8 HM-SEC-SDs and haven’t had any real issue yet. I press the “calibrate” (or whatever) button every few months and I had only very few fake alarms.

Same with the issues some are having with the LAN gateway. I only had ~2 “hangs” in around 1,5 year of operation and I have played around with it quite a bit.

#17

How many devices do you have in your configuration? As far as I’ve read in different forums the problems (hanging HM-LGW) mainly occur with complex configurations using ~100 devices or more.

#18

~ 70

#19

Since the new HM-SEC-SD-2 has been released a few weeks ago I wondering, if the siren can be enabled on demand as it was possible with the predecessor?

Wirrkopf, have you already had the chance of testing the new version?

We are going to buy about 10 devices for our house but the on-demand triggering of the siren is a mandatory feature for us. Thus I would really appreciate to get any feedback about the “inofficial” feature capabilities of the new HM-SEC-SD-2.

Thanks in advance for any help!

#20

Hey,

it should work. I didn’t test it though. If it really doesn’t work, it’s easily implemented - I just would need two or three devices to test.

Cheers,

Sathya