Everspring ST814 reports

[Thorden]

Hi,

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:

Programming
1. 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

Best regards,
Thorden
Oslo, Norway

[Thorden]

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. 

[nickrwym]

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.

Nick

[Ap15e]

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 urn:schemas-upnp-org:service:TemperatureSensor:1. The resolution as defined by the UPnP forum is 0.01 degrees Celsius. 20 degrees Celsius must be mapped to a CurrentTemperature of 2000 (not 20!). Either MCV should fix the bug or should use a service of their own for representing temperatures, setpoints, ...

[Thorden]

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!

 

[nickrwym]

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!

Nick

[Thorden]

Hi Nick,

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?
 

[nickrwym]

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.

Hope this helps

[Thorden]

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.

Could you please share the details on how you achieve this? How do you get the the Everspring/Vera link to be reliable?
Thanks!

[nickrwym]

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.

Could you please share the details on how you achieve this? How do you get the the Everspring/Vera link to be reliable?
Thanks!

Wish I could, I can only think it likes the larger variation in temperature that the outdoor one gets compared with the other one indoors.

Sorry I can't be more helpful but it just works!

Nick

[Thorden]

It would be great if you could share your ST814 configuration details. Like wakeup time, group associations and Device Options.
Do you poll it at all?

See the attached images from the config of my device.

Thanks!

[nickrwym]

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.

[Thorden]

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:
1) Polling (need a LUA code like the one you got, since Vera as I understand it will skip automatic polling of battery powered devices) 
2) A configuration change on the device in Vera
3) Automatic reports from the device, these are disabled as default. (but Vera won't receive them anyway, which is the main problem)

[nickrwym]

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.

Nick

[Thorden]

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!