Danfoss LC-13: Only within main controller range?

[ArPa]

Hi guys,

today I noticed that two of five Danfoss LC-13 thermostats are greyed out in Habmin after i changed the position of my Cubietruck.

Although the two greyed out LC-13 have enough neighbors nothing in log files for these two nodes (7: and 9:)

Then I found this manual (http://www.vesternet.com/downloads/dl/file/id/196/z_wave_danfoss_lc_13_living_connect_radiator_thermostat_manual.pdf) which says:

[...]
This device is battery operated and turned into deep sleep state most of the time to save battery
life time. Communication with the device is limited. In order to communicate with the device, a static
controller
C
is needed in the network. This controller will maintain a mailbox for the battery operated devices
and store commands that can not be received during deep sleep state. Without such a controller,
communication may become impossible and/or the battery life time is significantly decreased.

This device will wakeup regularly and announce the wakeup state by sending out a so called Wakeup
Notification. The controller can then empty the mailbox. Therefore, the device needs to be configured with
the desired wakeup interval and the node ID of the controller. If the device was included by a static
controller this controller will usually perform all necessary configurations. The wakeup interval is a tradeoff
between maximal battery life time and the desired responses of the device.

Click on the middle button will wakeup the device for wireless communication (if not in exception mode).

It is possible to set the node ID to 255 to send wakeup notifications as broadcast. In this mode device takes more time to
go to sleep and drains battery faster, but can notify all it's direct neighbors about a wakeup.
[...]

I also noticed that there are no "Association Groups" for the Danfoss LC-13. Is there something missing in the ZWave Binding Config Database for this device?

Anyone here who solved this similar problems with the Danfoss LC-13?

I'll try to set up the openzwave control panel on the cubietruck too. Maybe I can see some additional parameters there.

PS: If i change the position of my Cubietruck the two greyed out LC-13 get green after some time. But this is not how the Z-Wave mesh network should work, is it?

[Chris Jackson]

You probably need to make sure that the wakeup class is set correctly. In HABmin, it should show a destination node of 1 - if this is not set correctly, then the device will not work if it’s outside of the range of the main controller.

As far as I know, the Danfoss thermostats don’t support Associations, that’s why they aren’t shown in HABmin :)

Chris

[ArPa]

Sounds good, but there is no field in HABmin where I can set the destination node to 1. The only thing i can set is the Wake Up Interval.

Maybe I will find the correct field in the openzwave control panel?

The Associations thing confused me, too. The manual I found online (http://www.vesternet.com/downloads/dl/file/id/196/z_wave_danfoss_lc_13_living_connect_radiator_thermostat_manual.pdf) says something about:

Association Groups:
1: Target for Wakeup and Override Notifications (max. nodes in group: 1)

but the manual I got together with the Danfoss thermostats does not say anything about Associations. Confusing...

Will try to find the right setting for the "destination node 1" setup.

[Chris Jackson]

>
> Sounds good, but there is no field in HABmin where I can set the destination node to 1. The only thing i can set is the Wake Up Interval.

The binding will automatically set the node when you change the interval - just change to a different interval, then back to the same one if you want. If you are using the latest binding (1.7 snapshot) then it should set it automatically during initialisation.

[ArPa]

I'll get the latest snapshot of the zwave binding and try to do the trick with the wake up interval. Be right back...

[Chris Jackson]

Just for information regarding the 255 thing you mentioned - the reason this doesn’t work is 255 is a broadcast, which sounds good, however zwave doesn’t route broadcasts to stop them flooding the network. So, if you’re outside of the range of the controller, they can’t be used…

I’m about to go out so will respond to any queries later (or tomorrow).

Good luck.

[ArPa]

I did some additional tests with the latest zwave binding snapshot. The Cubietruck still stands on the most ´reachable position for all danfoss devices.

I changed all 5 devices to a wake up interval of 60 seconds. Then switched back to 180 seconds and did a time measurement on how long it takes the changes to apply.

4 devices reported the new wake up interval in under 60 seconds. Correct! But 1 device took about 150 seconds for this command although the wake up shouldn't take more than 60 seconds in worst case?

I'm still a little bit confused about the zwave mesh network. As I understood (and why I have chosen zwave) all permanent zwave devices should route the commands fast and reliable?

Now after all devices are back on 180 seconds wake up period I will change the main controller position again and see if the I can reach the yesterdays two refusing danfoss devices.

[Chris Jackson]

>
> 4 devices reported the new wake up interval in under 60 seconds. Correct! But 1 device took about 150 seconds for this command although the wake up shouldn't take more than 60 seconds in worst case?

It depends on the wakeup interval before you set this. Battery devices only wake up periodically. If you changed it to 60 seconds, then woke the device up by pressing the wakeup button, then it should have been set to 60 seconds. And then yes, it should have only taken 60 seconds to change it.

>
> I'm still a little bit confused about the zwave mesh network. As I understood (and why I have chosen zwave) all permanent zwave devices should route the commands fast and reliable?

Yes - that’s correct. But battery devices only wake up on a scheduled basis - based on the wakeup class. Also, as I said yesterday, broadcast packets (address 255) are not routed to avoid flooding the network, so previously your battery nodes would not have been routing the Danfoss packets if they were using broadcast.

[ArPa]

>
> 4 devices reported the new wake up interval in under 60 seconds. Correct! But 1 device took about 150 seconds for this command although the wake up shouldn't take more than 60 seconds in worst case?
It depends on the wakeup interval before you set this. Battery devices only wake up periodically. If you changed it to 60 seconds, then woke the device up by pressing the wakeup button, then it should have been set to 60 seconds. And then yes, it should have only taken 60 seconds to change it.

Yes, I know and that's why I say that it took much too long (2,5 times the wake up interval) the one device woke up. (maybe it woke up correctly every 60 seconds, but the main controller didn't get it?)

>
> I'm still a little bit confused about the zwave mesh network. As I understood (and why I have chosen zwave) all permanent zwave devices should route the commands fast and reliable?
Yes - that’s correct. But battery devices only wake up on a scheduled basis - based on the wakeup class. Also, as I said yesterday, broadcast packets (address 255) are not routed to avoid flooding the network, so previously your battery nodes would not have been routing the Danfoss packets if they were using broadcast.

 
Correct and that's why I say that the danfoss are not working correctly (at least in my zwave network).

And I don't say that it's the bindings fault, maybe it's a hardware or firmware issue of the danfoss lc-13.

All my danfoss lc-13 are set the same. wake up 180 seconds and with the latest zwave binding snapshot I see that the target node ist set to "1" too.

The system is up since 12:02 (for more than one hour now) with the new ("bad") main controller position. 3 devices have reported their set point in under 180 seconds. 2 devices are still "unknown".

All other battery devices (fibaro window sensors, fibaro motion sensors, etc.) are up and working correctly.

[Chris Jackson]

Ok, the only other suggestion I can make is that the RF link between some devices is not so good due to walls, microwave ovens, etc. and that’s meaning some messages get lost. Maybe moving things around will help - I can’t really say since I don’t know how far things are apart etc, but this is just something to think about…

It might be worth logging the data for an hour or two then running it through the log analyser to see what that says...

I don’t have any Danfoss devices so I can’t comment on them specifically. They are certainly devices that people are having some problems with…

Chris

[Kaz Librowski]

Hi ArPa,

I've just been forced to move my z-wave controller and now I'm experiencing the exact same problem as you. I can't connect to my Danfoss (presumably because it is out of range, it was working before), but I can connect to other battery operated z-wave devices that are even further away. So it seems my mesh is OK, but the Danfoss can't work with it. 

Have you had any luck fixing this (other than moving the controller within range)? I've tried doing heals within habmin, but no joy so far.

[morten...@gmail.com]

I have had some dropouts with my LC-13 device as well, and at first I could not make any sense of it.

However, the more I think about it the more i realise, that it could be the same problem as described above, as my dropout often happens when I close a door to the top floor, where the LC-13 is mounted. I guess that door could eat the last of the signal to the controller, which is in the basement.

Another note, which could belong in another thread, is that I have had my share of problems with the Aeon Labs 4in1 gen5 sensor. Where the only reliable data I was getting from it was battery, at an interval of four minutes, no matter what I setup in the configuration. Today I moved the device indoors, where am sure that it can connect to the controller directly, and now suddenly it is sending all the values and the battery at a consistent interval. Wake up also appeared in the log, which never appeared earlier.

Could there be an issue with some or all battery devices, being unable to talk to anybody else but the main controller? If this is the case, why was I getting Battery data when it was mounted outside, out of range of the main controller?

Best regards

Morten Attermann Holst

[cal]

Moin,

it does make sense to me if battery powered devices in a mesh network
typically talk to non-battery devices only.
I would expect some kind of non-battery repeaters to exist that store-and-forward
battery powered device messages.

Carsten

[Chris Jackson]

> Could there be an issue with some or all battery devices, being unable to talk to anybody else but the main controller? If this is the case, why was I getting Battery data when it was mounted outside, out of range of the main controller?

I doubt this is an issue - there’s nothing that can be done in the binding to change the way routing works - this is all handled by the protocol layers in the controller itself. I certainly have no problems with battery devices that are a long way from the controller.

It’s possible that these new devices need some configuration to (maybe) dumb them down when working with devices that aren’t ZW+. I’m not sure - i know they guys at OZW are also having trouble and Aotec donated them a bunch of stuff to help them try and work it out (since they aren’t allowed to actually provide information on the changes). If this is the case, then we may have to wait until this gets cracked…

I’ve not looked at my gen5 for a while but I think it’s also playing up so I need to find some time to have a look at what it’s doing…

Chris

[Chris Jackson]

> I would expect some kind of non-battery repeaters to exist that store-and-forward
> battery powered device messages.

This is exactly what zwave does. All mains powered devices act as repeaters, but I don’t think this is the issue we’re talking about here since the issue was that the battery messages apparently got through ok, but other messages didn’t.

Chris

[Morten Attermann Holst]

Exactly. And i have two mains powered devices that are in range of the battery device when placed outdoors. So routing should be covered.

I will find a purpose for the multisensor indoors while we wait for gen5 support.

I have actually also been providing a lot of logging and test scenarioes to a guy at Aeon. Let's hope that we can come up with a solution.


Venlig hilsen
Morten Attermann Holst

> --
> You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/zCaCbRwaXEU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openhab.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/17D22AA9-1913-4FB8-A4AD-47E2836A3DA5%40cd-jackson.com.
> For more options, visit https://groups.google.com/d/optout.

[cal]

Am Samstag, 21. März 2015 13:46:56 UTC+1 schrieb Morten Attermann Holst:

Exactly. And i have two mains powered devices that are in range of the battery device when placed outdoors. So routing should be covered.

Is it possible to make the "should" become an "is"?
Is it possible to actually debug routing issues to see if nearer stations are actually used as hops?

[Chris Jackson]

>
> Is it possible to make the "should" become an "is"?
> Is it possible to actually debug routing issues to see if nearer stations are actually used as hops?

No. As I think I said earlier, with zwave, the routing is all done in the protocol layer - we can’t influence it and we can’t find out what it’s doing. We can guess from some neighbour information that’s available, but it’s not the same - it’s basically not possible to know what routes are being used.

[cal]

From what i found skimming through  http://www.vesternet.com/resources/technology-indepth/understanding-z-wave-networks

Building Routes in a Z-Wave Network

Every node is able to determine which nodes are in its direct wireless range. These nodes are called neighbours. During Inclusion and later on Request, the node is able to inform the controller about its list of neighbours. Using this information, the controller is able to build a table that has all information about possible communication routes in a network. This routing table can be accessed by the user and there are several software solutions, typically called installer tools, that visualise the routing table helping you to optimise the network setup.

One should at least be able to find out if devices know about the neighbours you expect them to see.

I don't know zwave networks so feel free to shut me off if it's not helpful.

I know different networks in general and typically all have ways to debug issues on routing layer. (ping, TTL, etc.)

Just my thoughts from the outside ;-)

Carsten

 

[Chris Jackson]

This is only partly correct. Neighbour information is available, but ROUTES are not available. This is what I mentioned - neighbours we know, and this gives an idea of what routes are available, but not what routes are being used by the controller - this is not something we can access. The controller will typically try a number of routes, but we don’t know what ones - all we can do is assume that if there are a good number of neighbours, then it will likely work, and the tools that I’ve written for analysing logs etc do exactly this.

Please take a look at HABmin if you want to look at the neighbours - this information is available - both graphically and as a list. Again, this isn’t the same as routes. ZWave is a closed protocol - there is NO public information available on the protocol other than what has been reverse engineered or leaked. You must sign an NDA to access the information, and this NDA prevents you from disclosing it, and working on open source projects. This is one of the downsides to zwave - the (almost) total lack of real information.

Chris

[cal]

Hi Chris!

Thanks for that information!to
Seeing things more clear now.

The information that you miss in this thread: Is that something that is send by LC-13 as an event on its own using the route
it chooses or it was told at some time ago or is the controller doing a request and gets a response possibly telling the device how to route?
 
Thanks for your patience ...

Carsten

[Chris Jackson]

The controller sets the routes. It tells the device what routes to use between two devices - I believe it can give it a couple of options that it can try, but I’m not sure about this. As part of the heal process (which should happen each night if it’s configured) the binding will set these routes up - by this I mean we tell the controller to set a route from node x to node y, and the controller sorts the actual route out (hopefully!!).

What really happens under the hood is another question. Also, ZWave has other ways of keeping routes up to date. It uses explorer frames that a battery device can send to autonomously find a route - there’s limited information about this, and it’s only available in newer devices…

As I said, it’s one of the problems with zwave - certainly from an open source perspective - that there is limited information available about this.

[cal]

Thanks again.

It's a pity that this stuff is not publically available.

The FHEM project had some problems with same device. They found asking the relevant devices for battery status every 30 Minutes magically solved some problems ...

Carsten

[ArPa]

Hey guys,

sorry for my absence but I had very little time for my smart home project last days.

Nice to read that there are others out there with similar problems/observations regarding these danfoss lc-13. Unfortunately I could not find any solution so far in my setup.

I'm using 5 danfos lc-13. My test scenario is always the same. Changing the temperature directly on the danfos lc-13 and checking how long it takes in openhab to get the new values.

3 danfos lc-13 have direct connection to main controller. No problems with these so far. Values get updated in under 5 seconds. That's correct because if you push the buttons on the danfos lc-13 it's awake and reports value changes immediately.

One (bedroom) has a really poor connection to main controller. Sometimes it has, sometimes not. This one takes really really long to update the value in openhab. Sometimes it takes 15 minutes.

One (living room) has no connection to the main controller. This one is always green (alive) in Habmin but reports his values at best ones a day :(((

And YES, I think i have enough power supplied devices in it's direct surrounding. A fibaro window sensor which is mounted on a window directly above the heating has also no direct connection to the main controller reports his status changes within 5 seconds max.

I'm firmly convinced that it has something to do with a bad route implementation inside the danfos lc-13 because I also had some short time frames (1-2 hours) the living room thermostat worked perfectly without any problems. Then suddenly maybe it changes the route or something and nothing works anymore.

Maybe also the nightly network heal (it's activated in my setup) makes it worse???

My last idea is to get the living room thermostat working again (as it sometimes does) and then deactivate the nightly network heal job? Maybe this helps?

Has anyone checked the "battery status update" workaround? For me it's hard to believe that this helps but maybe we should give it a try?

[ArPa]

Although the manual is not very detailed I checked it again, because I noticed that on the displays of the two unreliable thermostats the alarm and antenna symbols are blinking in situations I can't get any values out of them via z-wave commands.

So the manual says:

Technical requirements and info

• After a successful inclusion the controller must send a WAKE_UP_INTERVAL_SET command to living connect Z in order to specify where and when living connect Z should communicate wirelessly. If not, the thermostat cannot perform wake ups and the alarm and antenna symbols will flash.
• The nodeID set in the WAKE_UP_INTERVAL_SET command must be for a permanently listening device which responds to the commands sent from living connect Z. This means PC´s with USB sticks will only work if the PC is never turned off.
• If living connect Z does not get correct and timely replies (e.g. if the controller is turned off) it will automatically switch to 30 minutes wake up intervals. If at next wake up the controller replies as expected, living connect Z will switch back to the original wake up interval.
• After sending the WAKE_UP_INTERVAL_SET command, the controller must assign return routes, so living connect Z can reach its destination, i.e. the nodeID set in the WAKE_UP_INTERVAL_SET command.
• living connect Z will not commence its periodic communication if its in "Mounting Mode".
• Although living connect Z supports single commands, multi commands must always be used to ensure two years battery lifetime.
• It multiple thermostats are installed in the same room, it is important that the controller ensures they all have the same schedule and the same setpoint.

Testing the connection

• Press O for at least 3 seconds until "M" is displayed.
• Press \/ until "LI" is displayed.
• Press O to test the connection.
• "LI" disappears when the connection is made.
• If no connection can be made, the alarm symbol and the antenna symbol flashes.
  

[Chris Jackson]

>
> Has anyone checked the "battery status update" workaround? For me it's hard to believe that this helps but maybe we should give it a try?

What is the ‘battery status update’ workaround?

Reading the bits in the manual, this should all happen - I’m not sure if you’ve pasted this because you think there’s a problem with something the manual wants or?

[ArPa]

The guys in FHEM believe that in their environment the danfos lc-13 only works correctly if they periodically (minimum once for 30min) send an "AT" command to the device:

define Atdanfoss at +*00:30 get <name> battery

Don't know what "AT" means in FHEM because I never used something else than openhab but if it means, that simply asking the device for battery status update manually, lets say with:

refresh_interval=1800

in the item definition??? I will try this but can't believe this resolves all my problems ;)

[ArPa]

Sources:

• http://forum.fhem.de/index.php/topic,32145.msg260795.html#msg260795
• http://www.fhemwiki.de/wiki/Z-Wave#DAN_LC-13_Heizungsthermostat_LC-13_.28014G0013.29
  

[Chris Jackson]

Sorry - I’ve no idea what this means as I can’t speak German. If it requires any changes from the binding, please let me know what.

Chris

[Chris Jackson]

Thanks for the explanation :)

I’m not sure if you can change the battery request period - let me check - it may be hard coded to 60 minutes (not sure why - it’s from before my time). If it is, I’ll change it...

[Chris Jackson]

I think it should be able to be overridden - the 60 minutes is just set as a default for the battery class…
Chris

[ArPa]

Today I woke up an saw the setpoint value 21.5 for my thermostat in the living room. Cool I thought and went to the living room to change the setpoint manually on the danfos lc-13 and check the connection today in the morning.

Sadly the living room thermostat is in ERROR E5 now :(

The manual says:

Error Code E5 = The thermostat is not receiving the expected replies from the control system. Check that you have a Z-Wave certified controller running and it has the necessary functionality to control the thermostat (see "Technical requirements")

Bedroom still not received any value since yesterdays system reboot.

No idea what to do?! I hate this danfos devices :)

Maybe I will try to reset the Z-Stick S2 and rebuild the network from scratch.... :( Don't believe it helps...

[Martin Naughton]

did you try moving the danfoss closer and sending wake up signal to see if the range is actually the problem?

martin

[ArPa]

Hi Martin,

yes of course. Changing the position of my Cubietruck was the only reason I noticed about that problem with the danfoss lc-13.

Changing the Cubietruck temporarily to the middle of our flat - absolutely unacceptable for my girlfrind ;) - resolves all problems. Also checking the neighbors in Habmin shows me: Only thermostats without main controller neighbor having the problems.

[hl_at]

Hi!

I only experienced the issue with Danfoss LCZ251 if the main Controller was not directly reachable. The LC13 works fine in My Environment.

[ArPa]

Do you remember how you initialized it?

I mean, if the main controller is not reachable in the end position of lc-13. How you include it into network? Maybe that's the magic?

There are several ways to do this. If you own a Z-Stick S2, you can try to carry the USB stick to the heating and push the button on the stick to activate the inclusion. Or doing everything without mounting the lc-13 onto the heating first and after the whole inclusion process is finished (including the neighbor update) mounting it to the heating then.

Maybe the inclusion procedure is decisive???

[Herbert Lackner]

Puhhhh…good question.

 

I had several issues with the Aeon Z-Stick 2 (zwave died every now and then completely à see several discussions here and on github) à switched to UZB stick with the new 500 chip.

The new stick has no button to include nodes à so I guess I included the lc-13 when it was mounted on the heating and the UZB-stick attached to the PC (2,5 rooms away).

 

I think with the Aeon Stick I mounted the lc-13 and took the z-stick with me to include it there – but cannot remember exactly. Question to the experts: It shouldn’t matter where the lc-13 gets included after a network heal is done – right?

 

Von: ope...@googlegroups.com [mailto:ope...@googlegroups.com] Im Auftrag von ArPa
Gesendet: Freitag, 3. April 2015 16:05
An: ope...@googlegroups.com
Betreff: Re: [openhab] Danfoss LC-13: Only within main controller range?

 

Do you remember how you initialized it?

I mean, if the main controller is not reachable in the end position of lc-13. How you include it into network? Maybe that's the magic?

There are several ways to do this. If you own a Z-Stock S2, you can try to carry the USB stick and push the button on the stick to activate the inclusion. Or doing everything without mounting the lc-13 onto the heating first and after the whole inclusion process is finished (including the neighbor update) mounting it to the heating then.

Maybe the inclusion procedure is decisive???

Am Freitag, 3. April 2015 15:38:33 UTC+2 schrieb hl_at:

Hi!

 

I only experienced the issue with Danfoss LCZ251 if the main Controller was not directly reachable. The LC13 works fine in My Environment.

--

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/zCaCbRwaXEU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/3d80f66f-b6fb-4f6d-8121-b6b80050ead4%40googlegroups.com.

[ArPa]

I ordered a "zme_uzb1" stick to check if it gets better with this one. As I read in the manual its ZWave Plus certified and has a much bigger range (inside rooms >40m) This could be the reason why the lc-13 has no problems anymore because the range for direct connections to the main controller is bigger?

By the way, Node Inclusion without direct connection to main controller is not possible. At least in "old" ZWave standard. ZWave Plus has a "new" possibility to do this as I know. But only with ZWave Plus Devices as I understand.

I will check the UZB-Stick and be back again in some days.

[Angel Luis Mateo Martínez]

Hello,

   Does anybody have any progress on this?

   I'm having this same problem. I have a ZME UZB1 Zwave plus controller in my computer (located in the basemen of my house) and 4 Danfoss LC-13. Two of this has no problems, but the controller doesn't receive any data from the other two, although they have at 2 meters a fibaro relay switch.

   The process to connect the danfoss to the network was:

- Connect the fibaro relay switch
- With the lc-13 disconnected from the radiator, and near enough to the controller, I connected it to the network. The device was included and have the fibaro relay switch as a neighbor. At this time, the controller receive data from it.
- Then, I moved the lc-13 to the radiator.
- Then, I didn't receive any more data from it.