EUROtronic Stella-Z

[matt (support)]

So .. if you send it straight back to sleep, the software has to wait the full poll interval for a retry?

Correct, in that situation that module will be skipped, but will most likely be processed the next time it wakes.

Does z-wave have collision detection or does it just transmit and hope?

Yes, the commands are acknowledged and resent using multiple routes if it fails. The problem is the Stella-Z's don't stay awake long enough that multiple wake polling sequences can be processed at once, so Indigo has to put modules back to sleep immediately if it currently processing a wake polling sequence for a different module.

The problem is the Stella-Z's don't stay awake long enough that multiple wake polling sequences can be processed at once, so Indigo has to put modules back to sleep immediately if it currently processing a wake polling sequence for a different module.

I wonder if the stella manufacturer would respond to a firmware change request. Can you tell from indigo if the z-wave chip in the unit can accept firmware updates, I think it depends on the chip type?

[matt (support)]

There is nothing we can tell on the Indigo side, so you'll have to contact Stella. I'm not sure how receptive they will be though -- they have it go to sleep after a few seconds on purpose to conserve battery juice.

Matt, this is gobbledigook to me but may make more sense to you and sounds interesting, from the Stella-Z manual:

"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."

Full manual here:

https://www.uk-automation.co.uk/pdf/stella%20z.pdf

Would that help matters?

[matt (support)]

I'm not sure if that would help or not. The purpose of that is for cases where you need your Stella-Z to notify more than one module that it is awake. The normal "I'm awake" configuration only allows you to specify a single target (Z-Stick in our case) for the wake notifications. What you see in the manual is away around that limitation.

I'm not sure if the side effect of it staying awake longer will really help or not. I'm really not sure we want the modules to stay awake longer -- they go sleep quickly on purpose to conserve battery power. I think we are just running into a limitation of how often modules that sleep can wake in scenarios where you have lots of them. There is always going to be limit at which point it stops working well given how the Z-Wave is defined, so all we can do is tune things to try to work optimally given the limitations. IMO, I'm impressed that having 12 battery operated modules that wake every 5 minutes is working well in a Z-Wave network with other modules also being commanded.

IMO, I'm impressed that having 12 battery operated modules that wake every 5 minutes is working well in a Z-Wave network with other modules also being commanded

Thats the bit holding me back to be honest. Its a bit more than 12 modules I'm going to need and I do ultimately want to put the lights etc. under control as well. I don't think the wife is going to accept a 10-15 minute delay between deciding she's cold and the radiators starting warming up, and she's definitely not going to be impressed with the idea of the lights not switching on because the network is busy dealing with the radiators...

So that leaves either EvoHome or similar as a separate option for the heating (but they all tend to be on the same spectrum so are they going to interfere with z-wave? there is mutterings of an API though which may mean it ended up linkable with indigo) or else looking at wired TRVs and plug in sockets to control the radiators (which is a good chunk more money once you allow for extra temperature sensors as well).

There is nothing we can tell on the Indigo side, so you'll have to contact Stella. I'm not sure how receptive they will be though -- they have it go to sleep after a few seconds on purpose to conserve battery juice.

One thing I am not understanding, I thought temperature sensing devices just wake up, send the temp, and go to sleep. Are you saying they wake up, then have to be polled for the temp, then go to sleep? Is that stella or do all temp sensing devices behave this way?

[matt (support)]

It varies. Some modules broadcast local changes as they occur, some modules broadcast values at specific intervals (sometimes settable via a configuration parameter), and some just wake up and have to be polled. I don't recall off the top of my head what the Stella-Z does.

Would it be possible to have an additional option for the Stella-Z to suppress writing non-error messages to the event log
At the moment the log is filled up with messages like:

Code: Select all

  Z-Wave                          sent "Stella-Z02" temperature status request
  Z-Wave                          received "Stella-Z02" temperature update to 17.0 °C


These are occurring every 5 minutes for each of my 12 thermostats.

Now that I have my Plugin in place, it keeps track of a thermostats temperature and only outputs a message when the temperature changes, e.g.:

Code: Select all

2013-11-10 08:44:09   Autolog Thermostat Controller    'Thermostat-10' updated from Stella-Z [Stella-Z10] with changed temperature 23.0 (was 23.5)

Suppressing the routine Stella-Z temperature messages would make the log smaller and easier to view

Would it be possible to have an additional option for the Stella-Z to suppress writing non-error messages to the event log

Alternatively, how about prefixing each log line with the device number? Right now indigo prints the interface type, could it append an underscore and the device number? Something like this:

Z-Wave_49 sent "Office Luminance" status request

That way grep can be used to fine tune the viewed log file. It would be possible to do things like this:

$ tail -f | grep Z-Wave_49

To just see log reports from device 49.

Steve

[matt (support)]

What happens if you try the "Hide temperature message broadcasts in Event" checkbox in the device settings dialog?

I think that will still show the "sent" message, but should suppress the "received" portion.

What happens if you try the "Hide temperature message broadcasts in Event" checkbox in the device settings dialog?

I think that will still show the "sent" message, but should suppress the "received" portion.

They were already all ticked - so it doesn't look like it is doing anything. Ideally it should suppress both the sent and received messages

[matt (support)]

Hmmm... are you positive (and you are running v6.0.4?)? Based on the code if that specific checkbox is enabled is should suppress the "received" log line. I've modified it to also suppress the "sent" line in 6.0.5 (to be released soon), but based on what I'm seeing the received side suppression should already be working.

Hmmm... are you positive (and you are running v6.0.4?)? ...

I think so and yes (6.04 on both the Client & Server)
Here is a log snippet:

Code: Select all

12 Nov 2013 17:08:06
  Z-Wave                          sent "Stella-Z07" temperature status request
  Z-Wave                          received "Stella-Z07" temperature update to 18.5 °C


and here is a view of the Edit dialogue:

Screen Shot 2013-11-12 at 17.09.44.png (148.24 KiB) Viewed 5873 times

[matt (support)]

Indigo 6.0.5 is now available and includes better suppressing of those log messages.