Chris, I was just sharing my experiences in hopes of helping the interested parties, and noting the lost opportunity to have integer-only temperature values throughout all code if the UPnP spec had been adhered to. And there are indeed presentation-layer issues in displaying decimals for temperature values, but you may not have encountered them in your work.
Apologies to anyone who misconstrued my comments to suggest that all temperature-handling code needs to be rewritten in order to address the specific need here.
Hi Watou,
No probs - I just wanted to be clear that there is a “simple” fix if MCV were to do this since they seem to have linked it to a major rewrite.
As with many things in Vera, it’s not well implemented but we can’t rewrite everything (unfortunately!). Most things can be worked around, but this particular issue is (IMHO) primarily related to the way MCV handle their Z Wave code.
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.[/quote]
Nope… As i have written elsewhere i have tried this with the rfxcom and the Oregon 132Ts When the real temperature is 25 celsius, Vera gives about 40 degrees. Thats about 15 degrees mistaken. In the past i use Siemens Logo and the acuracy was about +/- 0.25 c. That was for me not sufficient, but for temperature reasonable. But RLV had an offset aboud 1% rlv and that is not good. But now i should try an everspring 814 but it have an offset from 5% See the pdf: The humidity of trigger-ON and trigger-OFF cannot be set equal; there MUST be at least 5% difference in between. TERRIBLE 5% . For my exotic heliamphora plants i need a maximum of about 1 RLV so switch on at 70 and turn off at 71. I bought Vera for serious use, not als children toys! And temperature : Once the detector has been triggered, the temperature must increase or cool down at least 2。Cfrom the preset value before it can be triggered again. Even a Bi metal schould respond better.
Attached a picture of the measurement resolution you can expect using RFXtrx and an Oregon THGN132 sensor. Also you should be able to expect quite accurate readings from an Oregon sensor. If you are not getting correct readings I guess there is a bug either in the RFXtrx firmware or in the Vera RFXtrx433 plugin.
Yes thats what i am saying, the software is not good! I have connect the Oregon on my weather system and there the temperature was -0,7 different from my sensor in the shielding house. Thats a lot better than 15 c.
I have had similar issues with other type of sensors on the RFXtrx. I got greate support from RFXcom and got corrected firmware within days. Just provide good logfiles and explain the problem.
Too many unknowns to me as to why you are getting such wildly incorrect readings. Either there is something different about this model sensor, firmware bug, corrupted values, etc., etc.
Too many unknowns to me as to why you are getting such wildly incorrect readings. Either there is something different about this model sensor, firmware bug, corrupted values, etc., etc.[/quote]
I don’t know if you misunderstood me or not but just to be clear I am not getting any incorrect readings in my setup.
The picture I attached is from my outside temperature and it was a cold day yesterday until the evening when the sun came out + the sensor is hit with direct sunlight in the evening so sometimes I get a little spike at the end of the day.
I’m quite new to Vera and z-wave but for me the best thing about Vera is the RFXtrx433 setup. I have a hand full of cheep sensors working perfectly with both resolution and accuracy. My first impression of z-wave is that sensors are expensive some even ridiculously expensive and it sometimes takes you hours just to include one sensor correctly. One could expect that at that price you could also get some usability and resolution more than 1?C.
[quote=“dali, post:17, topic:168013”]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.[/quote]
A week has gone by, without any life signs from MCV support. It just shows how they don’t give a c**p about their customers.
I have heard from a person in “Leiden - the Netherlands” that he has the same problem like me, he used the rfxlan and got stupid measurements and now he has bought the RFXtrx and now the measurements are correct. Ik think i am going to buy a RFXtrx (and even try to connect an RFXSensor with 3 temp sensors.
Unfortunately RFXSensor is currently not supported by the RFXtrx433 plugin. This is something I miss also. I created a thread about it under RFXtrx433 plugin but got no response. Please comment in the thread, hopefully someone with coding skills will decide to make it happen.
I left a message too. There is a “somewhat constructive” answer from the director of product development, but in the same time, they would consider a fix for UI7??
i did write a note there on dali’s support question. asking MCV why they do not conform to the specs they agreed on in the first place . http://upnp.org/specs/ha/UPnP-ha-TemperatureSensor-v1-Service.pdf
look here at 2.2 table 1. it says REQUIRED 0.01 degrees C
Also, to continue the discussion, an implementation proposal was sent to @micasaverde a long time ago. Have not heard back.
Processing the Z-Wave sensor values in full resolution is no big deal, and displaying these values isn’t either, and also works with current control points.
Some thought needs to be given to event processing. Not sure how many plug-ins this would affect and if that really is such a big problem. I believe I proposed to make it user selectable, with the default being current behavior. I suspect that over time, things would migrate to the higher resolution.
I’d have to look up the communication; somewhere last year. But you can mention it was sent to @micasaverde, and I’m pretty sure I copied @mcvflorin as well.
Also, we try to raise/highlight ‘common’ issues (i.e. stuff that pops up repeatedly / is asked for by multiple users) on the private beta board. Regarding the sensor value resolution, one such mention was on 12/26/2011; and @Ap15e raised the UPnP issue on 12/19/2011, if not earlier.