Howto read temperature values with more decimal places

Other Devices & Integrations Climate Control & Temperature Sensors
1

Does anyone know how to read values from sensors with more decimal places like 20.1; 20.2 …?

I am using the vera2 as a platform for logging temperature values from different rooms in my house using Everspring ST814 and the ES 861 temperature sensors from LS Control.

Using the following luup call:
current_temp = luup.variable_get(“urn:upnp-org:serviceId:TemperatureSensor1”,“CurrentTemperature”,devnum)

I am only able to read absolute/integer values like 20; 21;…

As the ST814 is able to display tenths of degrees in the LCD display and I know by talking to the vendor of ES 861 that this will report temperatures with decimals, how can this be done on the vera2?

The capabilities of the two sensors are:

ST 814:
Capabilities: 82,156,0,4,33,1|32,49,96:2,112,114,128,132:2,133,134,
Nodeinfo: 20,31,60,70,72,80,84,85,86,

ES 861:
Capabilities 81,140,0,4,33,1|49,112,114,128,132:1,133,134,
Nodeinfo: 31,70,72,80,84,85,86,

FW version: 1.1.1047

2

Even if Vera would support reading values with more decimal places, it wouldn’t be possible to create events ‘Temperature goes above/below’ that take into account the decimal places:

http://bugs.micasaverde.com/view.php?id=1444

3

I am fully aware of the mentioned bug-report.

However, I do not need to use events, I only want to be able to read and log the temperature levels with more decimal places on a local server, to track smal temperature changes.

Therefore I am interested in finding out whether someone knows whether it can be done without going low-level.

Thanks.

4

[tt]CurrentTemperature[/tt] is declared as [tt]i4[/tt], so you would have to go low level (e.g., parsing the Z-Wave communication).

You could try changing [tt]i4[/tt] to [tt]float[/tt] or [tt]string[/tt] in [tt]S_TemperatureSensor1.xml[/tt], but I doubt that would work.

5

There could be a way for you in this post:
http://forum.micasaverde.com/index.php?topic=5988.msg35813#msg35813

6

Something new about this “problem” ? There is a way to get the a decimal temperature with LUUP ?

7

I raised this with MCV a month or two back when I first got my Vera. 1 deg resolution is pretty poor when the device supports more. I’ve also raised a bug/enhancement specifically on this point as the one Ap15e points out is slightly different.

My intention had been to use a number of the ST814 Z-Wave temp/humidity sensors, but I’ve currently given up on this and have started using one wire sensors. A company called EDS makes a temp/humidity sensor and an ethernet bridge, and I’ve written a plugin for this (see http://forum.micasaverde.com/index.php/topic,8381.0.html). The one wire sensors support fine resolution, and in the plugin I reduce the data to a resolution of 0.1deg - it works great and you can have up to 24 devices with the OWServer.

It’s not ideal, but as I suspect MCV aren’t going to change the low level code to support 0.1 deg any time soon (I hope I’m proven wrong - hint-hint!) by going down this route I’ve managed to get the functionality I want by other means (which I have a lot more control over). You’re still limited to 1 degree events though as pointed out by Ap15e.

8

Thank you for your reply Chris. I just configured my Vera to use fahrenheit instead of celcius. I have now an half degree celcius precision. Not perfect, but almost usable. :slight_smile:

9

Just bought a ST814 myself, should have read the forum first…

Although the device works well indeed only whole (rounded) degrees are reported!

Shouldn’t such an old and important issue be fixed by now? It seems there has not been any firmware upgrades for a long time - what is happening at Vera development?

If you cannot handle floating point event values, why not remove the ’ divide by 10 ’ in the zwave device code and report temperatures in 10th of degree integers?

The device reports the temperature as a 2 byte integer value in 10th of degrees, e.g. 195 is 19.5 degrees, vera’s / mios code divides this by 10 and rounds it to an integer value to make it centigrades, losing all precision in the process!

At least give me access to the original or 10x temperature value with the full precision so I can log or poll the temperature and control my room temperature more accurately for example!

(and it must be quite easy to show the decimal point in the right place on the gui display… , if not I still rather see ‘195’ than ‘20’)

[reading the ST814 device’s manual: the device reports the temperature in 2 sensor values , and to calculate the temperature Temperature(C) = (Sensor Value 1 * 256 + Sensor Value 2 ) /10. ]

I’m shocked, disappointed, upset,…,… by the lack of response from Vera to such incredibly crucial, basic, fundamental issues as those. Since early 2011 there are reports in the forum and tickets raised and ABSOLUTELY nothing is fixed ever! >:(

I even completely stopped opening tickets with vera support as they are generally not helpful, give absolutely no real solutions and report your case ‘resolved’ / ‘closed’ after 2 or 3 weeks without contacting you back!

Is there ANY WAY to customise the code on the vera box ourselves somehow to get access to the full precision temperature? I still don’t fully understand the components of the mios/vera box but I suspect that there’s a binary (/usr/bin/LuaUPnP) that has hardcoded knowledge of a bunch of pre-cooked zwave classes and forwards the received information to the rest of mios code handling events and GUI display… so it’s probably not possible to get to the temperature sensor value before it’s converted to integer? Why are the original values not accessible in luup code for example? That would still enable a lot of workaround solutions.

Any suggestions would be helpful, best would be to have the source code to analyse - I’m about ready to disassemble the code and debug the zwave serial traffic to find a solution…

An official answer from ‘vera’ would be appreciated as well as I’m severly loosing faith in this company, its products and its support!!!
. . .

10

I agree with lv. My idea and the reason I bought the Vera got totally useless by the fact its not supporting decimals.

I have been checking updates for more than a year without any updates on this issue. Is there any forecast when decimals can be expected to be supported (or there is a possible work-around available)?

11

I sent an email to support@micasaverde.com regarding this issue (and referencing bug 1817). The response I got was alot worse then I had expected:

Our development team has analyzed this feature request and have decided not to implement it because there's a very high chance to break other working z-wave devices. At the moment there are over 700 certified z-wave devices and we try to support as many as possible and sometimes this means we have to do small compromises. Sorry for this inconvenience.

I got very upset and sent them this reply:

This is NOT an acceptable response, and it's making me very upset!

First of all, this is not a feature request. This is regarding a bug, which was caused by MCV implementing temperature sensors the wrong way.
UPNP standard clearly states that temperature sensor values should be stored in .01 degrees centigrade, not in whole degrees.
Temperature values in whole degrees are completely useless when using it to do logical comparisons. One example is if I want to use temperature values to control my outdoor pool. The difference between 20 deg C and 21 deg C is to big!

Secondly, fixing this bug (and yes, it IS a bug) will not “break other working z-wave devices” if you fix the code. Sure, people would have to rewrite their lua code in scenes, but I’m convinced that they would gladly do that if it meant that they would get temperature values that are useful.

Thirdly, saying that this is a small compromise is quite ignorant. I have paid for a working z-wave controller, and I expect MCV to fix the bugs.

Lastly, why isn’t anyone from MCV responding to questions directed to you in the forums? You need to have a dialogue with the users, otherwise people get tired of the lack of response and gives up.

I’m close to giving up… MCV doesn’t seem willing to fix their bugs.

12

@dali - I would say to “give up” rather than frustrating yourself further. IMHO, there are numerous longstanding issues that affect more people, devices, and functionality than decimal precision in temperature readings.

If you find a better product, please come back and let us know about it. We’d all be interested in that.

13

Hi @dali

I feel your pain, but z-waver is right there is a long list of items that need addressing and this sadly will keep slipping down the list.

If you did want to see the decimal point on Vera, you would need to looks at something like the RFXrtx433 plugin and invest in some Oregon Scientific sensors.

For me this set up actually works much better than the Zwave devices i have and can work out cheaper too.

14

@Z-Waver; I’m not going to give up. We need to make MCV understand that it’s not an acceptable behavior. I know that many have tried before. But some day , when they go belly-up because they can no longer sell a product that they don’t support, they will probably get the message.

And it doesn’t matter if there are issues that affect more people, this issue makes the Vera unusable for me and other people.

15

@parkerc; An RFXtrx would probably do the thing. But I don’t want to use one-way-communication devices. I want to use the Fibaro universal sensor, and I would have been able to if MCV had done things right.

By the way. The fact that the RFXtrx plugin can set up temperature sensors as standard temperature sensors in vera only proves that MCV should be able to fix this without the risk of “breaking other working z-wave devices” as they said to me in their email response.
But who am I kidding? It’s not like they care, right? Or even bother to read in the forums… :frowning:

16

@dali,
You’re right to continue to push MCV on this. However, I originally raised this with them nearly 2 years ago, and I don’t see them changing it >:(. They’ve (incorrectly!) linked this issue to events - this isn’t right. Maybe they can’t use floats with events, but they can change the temperatures to support floats (as shown by other devices such as the One Wire, or RFX).

However, @parkerc is also right. The facts are that MCV are unlikely to change this, and actually, other solutions work better. I have Oregon sensors, OneWire sensors, and my own wireless sensors. I also have a couple of ZWave temperature sensors. The ZWave sensors actually update much less often than other sensors - probably for power reasons. If you wind the report period down, they chew through batteries. ZWave sensors are also very expensive for what they are, while Oregon, or OneWire are a lot cheaper (and a home brew system is even cheaper!).

So, keep pushing. I really think MCV should fix this. However, if you want to have a good system, then it’s worth thinking about an alternative along the lines of those suggested above.

Cheers
Chris

17

So, I got another email from MCV today. It took them four days to respond this time. One would think that it would be a detailed and response to my last email, since it was quite long and with a lot of questions. But no, it was just a standardized reply: “sorry for your inconvenience”, and a request that I write the whole thing again on their new support page.

So I asked them if they had even read what I wrote to them, and that I want them to motivate why they aren’t going to fix this.

18

Part way through writing the Nest plugin, I encountered the “no decimals” issue and was forced to round to whole degrees. It seemed to almost work to use tenths of a degree, but there was odd behavior. At one point I did have tenths of a degree Fahrenheit showing on the dashboard, but a remote client app would crash and there was other weirdness, too.

It’s conceivable that, if you have access to a particular plugin’s source code, you could try to hack it to use decimals, and then see where the problems with doing so appear. It’s unfortunate that MCV veered away from the strict UPnP spec of using Celsius times 100, so that all temperature variables would be in one format, but the presentation layer would be entirely responsible for converting to Fahrenheit, truncating unneeded precision, etc. It would now be a huge job to rewind the clock and fix all the code to handle all temperatures in one uniform way.

19

For simply displaying a number, there should be no issue. You can display as many decimals as you like (I do this in many plugins).

The only issue here (I believe) is that the zwave driver needs to not truncate the decimals. Apparently they did this as notifications need integers - fine, but clearly this can be limited just to notifications as is clearly shown by other plugins.

There is no need to do a wholesale change to standardise all temperatures.

Chris

20

just wonder why fibaro can do it and is based on mios and the same miosbased vera can’t …
most tempsensor wouldnt even have this precision the dallas tempsensor has but it is clearly stated in UPnP specs that it should conform to .01 degrees celcius… not using fahrenheit is coz only amerika uses this and is ihmo a stupid way to display temps. its like saying the windspeed is 5 steps of a human per second .