Store & Forward

[ScottRennie]

I have installed a StellaZ radiator valve with some issues. The manual talks about a store and forward 'mailbox' so when an event/job is sent to the TRV it is stored in the controller until the device wakes and reports in.

Does anyone know if Homeseer works in this way?

I am having trouble getting this to work. It works if I manually wake the TRV into include mode...

See the manual here
http://manuals.zwaveeurope.com/make....ku=EUR_STELLAZ

Cheers
Scott

<!-- / message --><!-- controls -->

[Rick Tinker]

We do have support for the wake-up command class, and we can queue some commands until the device sends us a wake-up signal, but other device commands are not queued by default unless it is a device we know about and set it up to work that way. This is because many times when somebody tries to operate a battery device that sleeps, they are not aware that it is asleep and expect it to work right away. We also tend to want to make sure that we have support for the command class that the device uses.

I looked over the command classes and do not see anything that we do not already support, so it should not be hard for us to support this device, although I will be adding support for new devices only in HS3 at this point.

I am contacting the Z-Wave Alliance because they have never included EUROtronic in the manufacturer information that I have. Once I have that I can blindly add support for the product and you can tell me if it works OK, and if there is some technical issue then we may have to wait for me to obtain one to play with before I get it working properly.

[ScottRennie]

OK Rick, Thats great - Thank You. Look forward to getting these chaps working

Cheers
Scott

[naellis]

OK Rick, Thats great - Thank You. Look forward to getting these chaps working

Cheers
Scott

Hello Rich, I'm looking to see how the Stella-Z TRV could be supported in HS. Ive got one and all looks promising as far as the Battery, Temp and Valve position wakeup reports in HS; but setting the Setpoint does not. It stays at a default 22C in what is called a 'Comfort' Mode. Sending a setpoint command thru HS returns ERROR in the debug log. The product appears to communicate reliably and accurately at every wakeup interval. Getting the setpoint command working would be brilliant - could it be supported please. If it helps I have shown below the log extract during the Inclusion to my network. If you need and debug log info please say.

Kind regards, Neil

12/02/2014 09:04:42 Z-Wave ********** Done with Z-Wave Device with Node ID of 78 **********
12/02/2014 09:04:24 Z-Wave Node 78 (Z-Wave Z-Wave Interface Z-Wave Thermostat 78) supports the Wake-Up Command Class Version 2 - Capabilities were retrieved successfully.
12/02/2014 09:04:24 Z-Wave Node did not report it's name or name not set, using the default name.
12/02/2014 09:04:24 Z-Wave Node did not report it's location or location not set, using the default location.
12/02/2014 09:04:24 Z-Wave Getting node and location name from device...
12/02/2014 09:04:15 ZWave Thermostats Devices Updated for thermostat: Z-Wave Thermostat 78
12/02/2014 09:04:15 Z-Wave Z-Wave device 78 version: Lib: 3.42 App: 0.4
12/02/2014 09:04:15 Z-Wave Device: Z-Wave Z-Wave Interface (Node 78) supports class(es): COMMAND_CLASS_BASIC, COMMAND_CLASS_SWITCH_MULTILEVEL, COMMAND_CLASS_SENSOR_MULTILEVEL, COMMAND_CLASS_THERMOSTAT_MODE_V2, COMMAND_CLASS_THERMOSTAT_SETPOINT, COMMAND_CLASS_NODE_NAMING, COMMAND_CLASS_BATTERY, COMMAND_CLASS_WAKE_UP, COMMAND_CLASS_MANUFACTURER_SPECIFIC, COMMAND_CLASS_VERSION
12/02/2014 09:04:15 Z-Wave Z-Wave manufacturer ID: 328=148H (UNKNOWN), Type: 1=1H, ID: 1=1H
12/02/2014 09:04:15 Z-Wave Attempting to get manufacturer ID from device 78...
12/02/2014 09:04:15 Z-Wave Contacting node 78 to get supported features
12/02/2014 09:04:15 Z-Wave **********
12/02/2014 09:04:15 Z-Wave ********** Adding Z-Wave Device with Node ID of 78 Type GENERIC_TYPE_THERMOSTAT=8H **********
12/02/2014 09:04:15 Z-Wave **********

[Rick Tinker]

Hello Rich, I'm looking to see how the Stella-Z TRV could be supported in HS.

HS2 = No.
HS3 = Yes.

So which are you speaking about?

[naellis]

Hello Rick, well my system is all HS2, so could just the setpoint functionality be added blindly ... That's really all I need to get per room radiator heating control going. What do you think ?

Cheers, Neil

[Rick Tinker]

Hello Rick, well my system is all HS2, so could just the setpoint functionality be added blindly ... That's really all I need to get per room radiator heating control going. What do you think ?

Cheers, Neil

I think no, as we stopped all development on HS2 a while ago. There are older model Danfoss radiator thermostats supported in HS2, but that is it. Danfoss Radiator thermostats are a huge pain in the butt! I am even having difficulty getting them working in HS3 because Danfoss likes to live in their own world void of any external controllers operating their devices! Work is ongoing, but in HS3 only.

[naellis]

So, if I upgrade to HS3 now, will it work ?

Regards, Neil

[Rick Tinker]

So, if I upgrade to HS3 now, will it work ?

Regards, Neil

If you tell me the make, model, product type, product ID, and version information then I can do some research and see if the possibilities are good, but as I mentioned above, work is ongoing.

The biggest issue is that unlike other battery devices which, once it wakes up, will stay awake as long as a node keeps sending to it (with a 2 second timeout) the Danfoss products always go back to sleep immediately after about 2 seconds, which makes it very, very, very difficult to work with it. I have changed a major portion of HS3 to better support devices like this, but Danfoss continues to frustrate. Their position of operation is based upon 3 key things (1. Battery life, 2. Battery life, 3. Battery life) that NOBODY else in the same position seems to be handling the same way as Danfoss. I don't really care if the battery only lasts one year instead of 14 months! They support the MULTI_CMD command class, which means that multiple commands are lumped together into a single transmission "to save battery life" but the interrogation of a node in HS2 and HS3 would have to be completely rewritten to support just their products to use this feature. As you can see, it is a difficult at best proposition.

[naellis]

Sorry but couldn't understand what Danfoss have to do with this product. It's manufacturer is EUROtronic Technology GmbH and has the Alliance conformance certificate http://http://products.z-wavealliance.org/products/826

If my HS Inclusion log extract is anything to go by then Stella Z does not support the MULTI_CMD command class you mention so I am hopeful it works more sensibly as you would want. So what info is needed to prove. Anything I would glean from inside HS logs that could help.

Regards, Neil

[naellis]

Stella Z product info as requested

Hello again Rick,
Please see the attached product details from the zwave conformance certificate. Does this provide enough for you to investigate its compatibility with HS please.

Many thanks,
Neil

[Rick Tinker]

Sorry - whenever somebody mentions Radiators I immediately go to the 400lb Gorilla Danfoss, who makes a radiator thermostat! It did not even cross my mind that it might be somebody else's when trouble is mentioned.

This is a VERY strange device indeed! I am not sure what the device does with the BASIC and SWITCH_MULTILEVEL command classes - basic is there probably so that dumb devices can control the thermostat, but nobody ever does that so it is the first time I have seen basic in a thermostat... switch multilevel is used in dimmer switches, which is the real perplexing one.

At any rate, it has the other command classes that support/work and so it is just a matter probably of making sure you have the latest version of the plug-in, because I did make some changes to how battery devices work (a little). Since it is a battery device, even the initial scan of the device will fail because the device goes back to sleep. If you go to the device properties and click Rescan and the device is not awake, it will schedule a rescan to take place the next time it wakes up. It is therefore very important that for a while at least, you set the wake-up interval to something kinda short (e.g. 6 minutes or 10 minutes) to make the setup as painless as possible. Go to the properties for the root device, then the Z-Wave tab, then Settings - the wake-up interval setting is there, but just before you click the SET button, you need to do something to the device to wake it up and then try to keep it awake until it can send that wake-up command setting. If you were successful, even if it cannot read what the current setting is because the device went back to sleep, you will start to see wake-up notices in the HomeSeer log at the interval that you set.

Once it is waking up, you can try doing a rescan and wait until the next wake-up to see how far the plug-in gets in discovering its capabilities. If the device is rude like the aforementioned ones and goes back to sleep even though HS is trying to communicate with it, then you will have to repeat this several times, as each piece of information that the plug-in is able to retrieve and store will allow it to progress to the next level.

Once it has created all of the devices for the command classes it supports, you will then be able to set a setpoint temperature, and the next time the device wakes up, it will be set on it. If you set a polling interval on the setpoint device, then the next time it wakes up, it will get the current setpoint setting. So if you eventually set the wake-up interval to 20 minutes but set a polling interval to 5 minutes, the system will still queue up only one poll command in the wake-up queue.

This ALL assumes that the device does not have any issues communicating with your HomeSeer controller - you may still have to fix communication issues by waking up the device and then doing an optimization of the device itself or the devices around it so that the Z-Wave interface on HomeSeer can figure out how to route the commands to get to the device.

[naellis]

Rick,
So to recap on the current behavior of the device in my network, it Included without any hitch and created 4 devices as follows:-

1. Root which shows under status column

Temperature: 0C
Setpoint (Heat): 22C - this is the current default under "Comfort" mode
Mode: Heat

2. Battery Level: 86%

3. 20C - this is the actual room temperature

4. Dim, 97% - this is the switch multilevel device which can allow direct control of the valve if the Stella Z Mode is changed to "Direct Valve Control" mode

The only configuration parameter under Root is the Wakeup period which I have set to 15 Mins - and it communicates like clockwork to update the actual Temperature and the Battery Level in HS.
There is no option to set a Polling Interval so I am not sure what you mean by setting one.
Being a non-listening device (like for example my other Horstmann HRT4 devices) I was expecting HS to queue a Setpoint change request and wait for the device to wakeup. That doesn't seem to happen when looking at the log....but you may want to ask me to look more specifically at the debug messages to give you further information.

As far communication on my network, the device indicates "Acceptable (8)" in the WhoAmI page in HS.

I have attached the product Manual for your attention also as it describes the Modes available and the Command Class mappings to switch between them; but my primary goal is to manage the setpoint.

I remain hopeful

Kind Regards, Neil

[Rick Tinker]

... and created 4 devices as follows:-
1. Root which shows under status column

Temperature: 0C
Setpoint (Heat): 22C - this is the current default under "Comfort" mode
Mode: Heat

If I am reading this correctly, then this is already a problem - the root device should not show these things. YOU ARE RUNNING HS3 RIGHT? The root device should show nothing and there should be a child device that says it is the Heat Setpoint device.

2. Battery Level: 86%

OK

3. 20C - this is the actual room temperature

So this should show as being a Sensor Multilevel device (temperature)

4. Dim, 97% - this is the switch multilevel device which can allow direct control of the valve if the Stella Z Mode is changed to "Direct Valve Control" mode

OK, now I understand that feature. Makes sense - most of the time a valve is fully open or completely closed. By limiting the amount of hot water flowing, it may be possible to maintain the temperature without causing the boiler to have to fire up more often - nice.

The only configuration parameter under Root is the Wakeup period which I have set to 15 Mins - and it communicates like clockwork to update the actual Temperature and the Battery Level in HS.
There is no option to set a Polling Interval so I am not sure what you mean by setting one.

On the page, there is a slider for Information About Node XXX, then a heading that says Options for Node XXX, then the node number, and then the Polling Interval.

If you set a polling interval on the root device, it will poll every child device at that frequency, which you do NOT want. Set a polling interval on the device for the SETPOINT and the TEMPERATURE to as often as you need to know what they are - e.g. if your wake-up interval is 15 minutes, then set the temperature one to 14 minutes, and the setpoint one to perhaps 29 minutes since you should know when you change the setpoint and 30 minutes would probably be enough notice if somebody manually changes it, but it is up to you. The battery device should have a polling interval of 12 hours or perhaps 18 hours. Bottom line is that the least amount you can poll the least number of devices, the longer your battery will last.

Being a non-listening device (like for example my other Horstmann HRT4 devices) I was expecting HS to queue a Setpoint change request and wait for the device to wakeup. That doesn't seem to happen when looking at the log....but you may want to ask me to look more specifically at the debug messages to give you further information.

Commands to a device always show in the log when they are carried out - there will be an entry mentioning CAPI. That just means that HomeSeer passed a device control API (CAPI) command to the plug-in (or itself) responsible for making it happen - in this case, there may also be an entry saying that the command was queued to be sent when it wakes up, and if not, then I neglected to add that. There should be a new version posted soon though so I would wait until that comes out before we worry about this one - I keep moving forward and would have to look through the source control logs to verify when I changed how these are processed. The bottom line is, after waiting for your wake-up time, does the setpoint change happen?

As far communication on my network, the device indicates "Acceptable (8)" in the WhoAmI page in HS.

That is good, sounds like little change of communication issues and since all of the devices appear to have been created (although that root device I do not understand, so please clarify) I think that verifies that communication is good.

[naellis]

Rick, I have HS2 so can you confirm what you want me to look at for polling settings.

Cheers, Neil