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?
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+).
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?
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?
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.
[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 . The CUNO already is supported. But I don’t recommend using it, as the timing is horrible and the bidirectional communication often fails.
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
that’s really cool ! 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 .
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…
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.
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.
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.
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.