I am struggling to get any updates from the Everspring ST814 Temp/Humidity sensor in Vera.
The ST814 is supposed to send reports to nodes in association group 1, and basic commands (on/off) to nodes in association group 2. The latter works just fine for me, using Vera device ID’s (not the altid’s).
I have tried to put ID #0, 1, and 2 (separately) in Association group 1, but it seemingly doesn’t do anything at all, or at least Vera doesn’t display any updated data in the GUI. I also tried to leave the group 1 empty, same result.
Anybody succeeded in doing this, or doesn’t Vera support receiving these reports? Is there a way I can see if Vera receives them at all?
Any suggestions are greatly appreciated!
From the ST814 documentation:
[i]Programming
Z-Wave’s Groups (Association Command Class Version 2)
The Temp./Humid. Detector can be set to send reports to or control associated
Z-Wave devices. It supports two association groups with one node support for
Grouping 1 and three nodes support for Grouping 2.
Grouping 1 includes POWER_APPLIED, SENSOR_MULTILEVEL _REPORT,
ALARM_REPORT an d BATTERY_REPORT_COMMAND
Grouping 2 includes BASIC_SET [/i]
Is really nobody using the Everspring ST814? Would really appreciate to hear other people’s experience with this device and Vera.
I just upgraded to UI5, no change.
I submitted a trouble ticket to MCV weeks ago, no response. ???
I had planned to use the ever spring to control my heating via vera but gave up due to the poor updates I was getting.
It depends what you want to do with it, I have one logging outside temperature and that works ok. The indoor one was very slow at reporting temperature changes to Vera. Vera also rounded temperature to the nearest degree rather than the device resolution of 0.1 degree.
Vera also rounded temperature to the nearest degree rather than the device resolution of 0.1 degree.
Vera once again doesn’t conform to the UPnP specification for [tt]urn:schemas-upnp-org:service:TemperatureSensor:1[/tt]. The resolution as defined by the UPnP forum is 0.01 degrees Celsius. 20 degrees Celsius must be mapped to a [tt]CurrentTemperature[/tt] of 2000 (not 20!). Either MCV should fix the bug or should use a service of their own for representing temperatures, setpoints, …
The resolution certainly is a major issue, but that Vera for some resaon won’t receive the auto-reports from the device is a huge show stopper too.
This could be an error in the ST814, but I seriously doubt it. It works fine with other controllers like Homeseer as far as I can understand.
If Vera could receive the auto-reports, there would be no need for frequent polling and short wake-up intervals that rapidly consumes batteries and allows for big variations in temp/humidity. These two problems makes Vera unsuitable for controlling temperature. I wish MCV could comment on this, or at least respond to trouble tickets!
Vera is fine for temperature control, just not with the Everspring.
I have had my heating running under Vera for several weeks now and have the setting optimised. The “one wire” solution that Chris developed works well, 0.1 resolution and rapid update into Vera. It’s wired ethernet, not Zwave but works fine for me.
A small amount of Lua code made temperature control very viable, there is a Zwave appliance switch that powers a relay that then provides volt free contacts to the heat pump thermostat terminals. This is where the Zwave helps a lot. the distance from Vera to the boiler/heat pump control would have been a pain in copper.
There is an Everspring that is recording outside temperature and this is working fine, it seems to like the large variations it sees, it was the inside one where temperature was only going up or down a degree or two that was unreliable.
I’ve put a screen grab from Datamine showing the last 24 hours of inside and outside temperatures, the first half of the screen shows a deliberate reduction in temperature during the night. Vera with the One wire and the right code is giving me fine control over the heating. Thanks to Chris for Datamine and the One Wire plugin!
Thanks for your input! I would certainly like to know more about your solution to see if this is something I can utilize. But I am afraid my options when it comes to running wires are limited in my scenarios.
You say your outdoor Everspring works fine, can you share more information about that? How do you get the temp readings to Vera?
I’m lucky in that the main network hub is in the centre of my house and in a reasonable position for temperature sensing. The One Wire server plugs into the network anywhere you have it. You can also get a wifi version so that would only require mains, generally that can be found somewhere.
The Everspring with the outside temperature is in a small lean to greenhouse just outside the house and is linking back via Zwave to Vera reliably. you can see from the DataMine screen shot that the outside temperature is MUCH coarser than the top trace off the one wire chip sensor. Chris developed the plugin for that and it’s been very reliable.
I use a small luup script that I gleaned from the good folks here to perform temperature control as the “obvious way” of using a scene to look for an “event” of temperature going over or under a set point was unreliable.
The scene I use has a 5 minute timer that makes the scene run, in the Luup field I have this
local lul_temp = luup.variable_get(“urn:upnp-org:serviceId:TemperatureSensor1”,“CurrentTemperature”, 52)
if (tonumber(lul_temp) <17.5) then return false
end
52 is the ID of my temperature sensor.
This script returns false (ie does nothing) if the temperature is under 17.5 centigrade. If temperature goes over that point it returns true and it’s “command” operates which is to turn the heating off.
There is a corresponding version with a > that turns the heating on and versions of this with “time between” Luup code that set different temperatures at different times of day. I have found that around 0.4C is enough difference between the on and off points to get the heating to cycle nicely. Again DataMine lets me check how it’s been running.
it’s working out well, a comfortable temperature without overshooting and wasting energy.
There are Living Connect valves on the bedroom and living room radiators that restrict the times of day I heat those rooms at.
it’s all at the default settings that Vera installed it at on UI4
This one behaves itself, my gut feel is that because there is plenty of temperature variation it has something to say about so works
Vera rounding to the nearest degree would make the inside one useless even if it did update, I am using a 0.4C difference between heating on and heating off so Vera and Everspring just are not an option.
So the device with ID #52 is your ST814, or do you use a similar code for the ST814?
Then it makes sense, since you are forcing a poll with your “luup.variable_get” statement every 5 minutes, which it will (probably) respond to at every default wakeup interval of 30 minutes.
It can’t have anything to do with temperature variations.
There are only three ways you can get the data from the sensor and into Vera:
Polling (need a LUA code like the one you got, since Vera as I understand it will skip automatic polling of battery powered devices)
A configuration change on the device in Vera
Automatic reports from the device, these are disabled as default. (but Vera won’t receive them anyway, which is the main problem)
Device 52 is my One Wire sensor, that one updates nicely. The “timed poll” works infinitely better than setting an event for a temperature passing a given point as Vera seems to miss that more often than not.
I am running similar code on the outdoor Everspring though to give myself a “10 mins on 20 mins off” heating cycle during the day if the house is unoccupied and the outdoor temperature is below 5 degrees, this stops the inside temperature sinking too far in cold weather.
I’m playing with different algorithms on the heating and getting good results in terms of comfort vs energy consumed.
Well, that explains how you get the readings from the ST814. Without the LUA code, you would get nothing.
I do it in a similar way: luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”,“Poll”,{},22), which just polls it and reads all parameters.
It’s OK, but to be anything close to useful in my situation the ST814 needs to have a wakeup interval of 10-15 minutes, as temperature may vary a lot. That kind of wakeup interval will probably drain batteries in 4-6 weeks. :-\
Is it possible to create a dummy “Thermostate” device in Vera and use it to enter the desired temperature/set point? And then use the set point value of this device in a LUA code to compare against the sensor reading? That would be nice!
I was getting the updates on my “outdoor ST814” BEFORE I put the Lua code in to make use of it. Until then it was just logging data into DataMine and displaying on the dashboard.
It’s possible that Datamine is stimulating it in some way, Chris may be able to help there?
I have no idea about creating your dummy device, I’m a novice here feeling my way, I’ve got some things working well but there is a lot that I know nothing about.
There are lots of people out there that have much more experience than me.
If you are doing temperature control I would thoroughly recommend changing to the “one wire” server and sensors though, much better updates and much better resolution. You can get a wifi version so you can put it anywhere you have power and run wifi back to Vera.
I have no problem with the ST814. It doesn’t update very often, but it works ok. I have the following settings -:
[font=courier]Var 6 - 2 byte - val = 5
Var 7 - 1 byte - val = 1
Var 8 - 1 byte - val = 5[/font]
I don’t believe that you can poll a Z Wave battery device (but I may be wrong) it only wakes up periodically, and you can’t poll it when it’s asleep. The above settings are assocaited with how often it sends updates, and how much the temperature or humidity needs to change for it to send out a message.
I had the exact same settings as you, nothing happened.
Var 6 = 5 means it should report status every 5 minutes
Var 7 = 1 means it should report status every time the temp changes by 1 degree
Var 8 = 5 means it should report status every time the humidity changes by 5%
Does it do any of this in your system? What if you put the device in the fridge, will it report the change in temperature within 5-10 minutes?
Yes, you can poll it, but only by adding some LUA code. I created a scene with this code luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”,“Poll”,{},22)
(My device is #22)
Set a timer on the scene so it runs at given intervals, works OK. It obviously only succeed in polling every time the ST814 wakes up (If I’m lucky), all other polls will fail.
I’ve not tried putting it in a fridge. I don’t think it is working quite as I’d expect, but it does update. I think you can also force an update by pressing the second button from the left 3 times.
Attached is a picture of what one of my ST814s does - I’ve got 2 of them and they both work similarly (which isn’t brilliant, but it’s ‘ok’). Blue is temp, and green is humidity.
Well, I managed to create it, and started playing around with it. Promising, but not quite stable yet.
Pretty easy (UI5): Apps/Develop Apps/Create Device
Upnp Device Filename: D_HVAC_ZoneThermostat1.xml
Description: What ever
I get a lot of “No Implementation” errors when changing values, no clue why. And it seems to clear the set temperature and the UI randomly.
