Autolog Stella-Z Thermostat Controller Discussion

Somewhat unrelated issue. I'm having an issue with the control page for showing the state of the TRV's. When I use the Device State as text , and select the plugin TRV rather than the actual TRV, and use Mode ( on or off ), it correctly displays as off when outside the schedule and not boost. However when i use an on/off icon, it constantly shows the +on icon indicating On. Under Devices, the state of the plugin TRV shows as Off so i would expect it to show the off icon.

I reworked this in the V2.0 version, so it may work now - it does for me. I have setup additional images in the Indigo 6>IndigoWebServer>Images>controls>Devices which are as follows:

Grey flame:

'autolog+.png'
'autolog+false.png'
'autolog+inactive.png'
'autolog+off.png'

Orange flame:

'autolog+active.png'
'autolog+on.png'
'autolog+true.png'

Red button:

'autolog+delay.png'

The Red button is shown when a Stella-Z has missed a wake-up.

I think I have now done the changes necessary to handle non-ZWave remote thermostats but haven't had time to update the documentation yet. I can let you have a 'beta' copy if you want but realistically I don't think I will get round to updating the documentation for at least another week or so.

The main changes are that internally the majority of the processing now gets handled in the runConcurrentThread to make the Plugin more robust and I have dispensed with using external schedules. These are now defined in the device configuration. So where previously you would specify an external schedule, you now define the start and stop times directly. There are also various bugs that have been corrected

Yeah would love to give V2 a go

Yeah would love to give V2 a go

This is an example Control Page for an Autolog Thermostat:

Control Page Example.png (51.14 KiB) Viewed 8779 times

Here is a screen shot of a control page from the upcoming V2 of the Plugin:

Hi Autolog

I've read all the posts that led to your plugin and it's clear you did what I (recently) wanted to do with our respective central heating systems. I take my hat off to you

Some years ago I hardwired thermometers around my house and controlled my antiquated boiler with VB code and a simple on/off relay. Primitive as it was it still saved 30% on my gas bill from just a thermostat...

Now, with a new boiler and an upstairs/downstairs zoned system, I decided to look into using zwave TRVs to micro-manage my heating. I started down a path you had already trudded. Trodded. Er - well, trail blazed, by the look of it.

If you haven't already come across it, you may be interested in a project called openHAB. It seeks to provide a message bus for many disparate systems related to Home Automation and they have bindings for everything from zwave to Sonos, XMPP to MQTT. The point is to link them all together and I think (if you haven't come across it already) that you could make a substantial contribution to what they are trying to do. Or maybe Indigo would be the people to link - not sure. Both, probably.

For me, I was very excited when I saw your first posts about zoning the entire house. This was my Holy Grail. Unfortunately, bit by bit, I saw how difficult it would be for me to translate your efforts into a Windows zwave platform, using the same zwave usb stick, but without a MAC or the programming skills.

I also became a little dismayed by the very nature of battery powered zwave devices. Sleep time, short wake-up times, mesh network rules... Limits on the number of TRVs, limits on zwave device functionality, timing issues... It made me think back to hard-wired devices and just how easy they are to deal with. Ugly wiring, I agree, though if you're a dab hand at internal decorating it's actually not that bad. My ADT alarm installer put sensors all over the place but you can't see any wiring till you go to the control unit in the garage. Of course, their monthly charges were why I cancelled my contract and built my own VB controlled system. Same one that handled heating back then.

I would be faced with all the same challenges as you if I go zwave.

I've been trialing a door contact/PIT/Luminence/temp/battery sensor to see how it performs and already, it seems to miss the odd activation. Probably a timing thing that could be fixed in code but it would need to be fixed. If I want to alarm my house, or use zwave to control my fuel bills I need to be certain it'll do what I want. A smoke alarm is no good if it's not 100% reliable.

I'm not smart enough to fix that.

So sadly, I have decided to re-use all my wired door/window, PIR and glass-break sensors into a new openHAB system with a parallel approach. The Alarm siren will be hard wired but the wire free notifications and Android alarms go off too (a little earlier).

My heating will retain it's existing British Gas wire-free thermostats and receivers - I won't be buying SCS317s, but I will install a few zwave TRVs in those rooms that need a much more binary control. Like "my kid is staying over, her bedroom is active" or "I have friends staying over, spare bedroom is active".

I'm disappointed to be saying this. I really hoped I could (like you) fine tune my presence in my house with my heating system but when I look at the return on investment of time, effort, programming, debugging etc., I just can't do it myself.

I wish you well with your heating project and I firmly believe you've nailed the requirements. I want the same. Push the vendors to allow sleep-time to be programmable. Maybe suggest ways wake-up stays on long enough for transactions to complete. Zwave is always moving forward and it's people like you that are driving the standard. These are real life use-cases, not just envisaged applications.

Have a look at openHAB. Kai Kreuser is the main man and he's very approachable. You could integrate your system into something a lot bigger.

Cheers
Vitch

I've read all the posts that led to your plugin and it's clear you did what I (recently) wanted to do with our respective central heating systems. I take my hat off to you

Thanks for the kind words

Have a look at openHAB.

Whilst I appreciate there are other alternatives, I am totally committed to using Indigo as my Home Automation system and don't have the time or desire to look elsewhere. Indigo provides me with what I need for my current home automation requirements. I like that it gives me the flexibility to add in extra functionality, has excellent support from the Indigo developers (Matt and Jay) and a very helpful and pro-active user forum.

[jay (support)]

@Vitch - I wonder if you were using Indigo rather than OpenHAB if it would be such a chore, particularly given that Autolog seems to have solved at least many if the problems...

I've read all the posts that led to your plugin and it's clear you did what I (recently) wanted to do with our respective central heating systems. I take my hat off to you

Thanks for the kind words

Have a look at openHAB.

Indigo provides me with what I need for my current home automation requirements.

autolog .. any chance of an update, let us know how your system is performing. You now have several months experience with it so it would be great to read your thoughts...

Steve

...any chance of an update, let us know how your system is performing. You now have several months experience with it so it would be great to read your thoughts...

I guess the answer splits into two parts: A) The Stella-Zs and B) Indigo and my Plugin.

As far as the Stella-Zs go, they are generally OK. I used to have conrad FHT80Bs (used via FHEM). I prefer the Stella-Zs as they confirm or otherwise that they have received the commands. The jury is still out on battery life. I think the wakeup frequency is a big factor in how long they last. Ideally, you should be able to alter the wakeup frequency dynamically via Indigo (I think this may be on "the list"?) which could extend the battery life.
They are affected by heat from the radiators and using a remote stat can help with this. Overall though, I am not sure there is any better thermostat. I have got a Danfoss to play with but I am not impressed so far.

As far as Indigo and my Plugin go, it has been great to be able to develop my heating control system to provide a very granular level of control. In actual use it has been very flexible and has reduced our heating bills. I have set-up a series of control pages (shown earlier in this thread) that enable individual control of all the radiators. There is a fair bit of error recovery built into my Plugin to handle situations where a wake-up is missed or there is a Z-Wave error of some sort. This happens on an infrequent but regular basis so needs handling.

I think the next things I will do to extend it are a) cater for multiple thermostat types (i.e. more than just Stella-Zs and b) add some "intelligence" in to the system (e.g. start the heating earlier if it is very cold outside, interact with other sensors etc). Something to do in the background over the summer, ready for next winter

So in summary I am quite pleased with the system and it meets my current needs

Hi Autolog,

I've got 12 LC13 Danfoss devices, they are very reliable with Indigo - no any errors at all (no panic mode, etc).

I'd be happy to see your plugin more "generalised" to use my LC13... I can be a beta tester

A lot of devices, including netatmo, fibaro motion sensor, aeon 4-1 motion sensor, HRT-4ZW, etc.

... I'd be happy to see your plugin more "generalised" to use my LC13... I can be a beta tester ...

I have started work on a more generalised version (Autolog TRV Controller) and am testing with a LC13. However, I am currently trying to resolve a problem with handling a setpoint change made on the LC13. I am sure it isn't insurmountable but other things (mainly non-Indigo) have got in the way of progressing this.

Your request is a timely reminder for me to take another look at it.

Once I have something that works you are welcome to beta test it.

Thank you for the reply provided

By the way, some (not sure how easy to implement) idea is to pre-programm LC13 - much better efficiency in terms of battery life.

Quoting myself: "COMMAND_CLASS_CLIMATE_CONTROL_SCHEDULE and COMMAND_CLASS_MULTI_CMD on a new Danfoss LC13

It will be extremely helpful to massively increase battery life (many times), as well as to be able to manage temperature much more precisely"

The issue is that right now the only way is to use raw z-wave commands

viewtopic.php?f=84&t=12608&p=84899&hilit=lc13#p84899

I can sign up as a beta tester for Danfoss version as well, keep me in mind

Wondering if you have thought about any method for calibrating the Stella temp? By this I mean using a method whereby the user records the room temp with a secondary thermometer and compares it with the Stella reported temp over time, as the radiator heats up.

Like everyone else I've noticed that when off it's accurate, but the temp differential increases as it heats up. Was thinking that one could start at cold and as it heats up record the room temp every 2-5 minutes and log that with what the Stella is reporting. That way your plugin could use this internal graph to more accurately manage the Stella. That way we ignore the temp from the Stella and just your your plugin to set the temp which internally it would know what to set and expect from the Stella.

Hope that makes sense.

Simon

On reflection, one would just need to place another temp sensor, which is more accurate, in the same room over the heat up period that the plug in could periodically poll for updates to build its room heat up profile.