Issue with stored value versus live values?


#1

Thank you for taking the time to submit your bug/issue! Please use the points below as a guide when submitting.

  • Device & model you are using (MQTT from Windows/Linux)

  • What dashboard are you using? (Web)

I have a persistent Thermometer widget on my dashboard. I send temperature in Fahrenheit. My last value sent from my device was 82 F.

I logged in from another web browser and the temperature showed 179.6. (which is 82 Celsius converted to Fahrenheit). Also, I refreshed the browser that showed 82 F right after the update and it changed to 179.6. So it seems Celsius is the default unit but the value is being saved as Fahrenheit so when the widget is resent the value from storage it is being re-converted to Fahrenheit. Seems you want to convert back to Celsius to save values so that devices show the correct last value when data is resent to widgets from your server.


#2

I see this too, both in iPhone app and web. Even though I’m posting in F I think somewhere internally, both systems think I’m posting C and then converting to F for display.


#3

Hi @bmckay, @barryhannigan,

Could you both share the statement you’re using to post these temperature values in F so I can reproduce/investigate?


#4
 client.virtualWrite(1, temperature, cayenne.client.TYPE_TEMPERATURE, cayenne.client.UNIT_FAHRENHEIT)
  client.virtualWrite(2, humidity, cayenne.client.TYPE_RELATIVE_HUMIDITY, cayenne.client.UNIT_PERCENT)

#5

I have another sensor which does it to but the line is of the same format. I should note, the web app doesn’t seem to correct itself but the iPhone app will; I think after a new value is posted.


#6

Ok, yeah, that’s pretty straightforward to reproduce, just publish the value and refresh the browser. Apologies for the bug – I’ll us started on fixing it. In the meantime, with a caveat of losing the text label that says ‘Fahrenheit’ you could work around this by passing the same data to an Analog Sensor widget which won’t have this conversion bug, with something like:

virtualWrite(6, 82, "analog_sensor", "null")


#7

Very cool website/app otherwise.


#8

Appreciate the kind words, we’ll get this squashed ASAP. Thanks again for the detail in your report.


#9

Just seeing this now.
Looks like bmckay’s response gave you what you needed to reproduce.

For me, two easy ways to reproduce, either just refresh the browser between data updates or log in to a second browser session between data updates.

I did another test where I logged in from 2 browsers, and on one I changed the unit to Celsius and left the other at Fahrenheit. When I run my code and send the value through MQTT each browser updates to the correct value for its unit. I send the MQTT payload with temp,f=82 and the Fahrenheit reads 82 and the Celsius reads 27.78.

So the live update works fine, but then if I refresh the browser I had changed to Celsius, it reads 80 Celsius. It seems on a browser refresh the value returned is the value from the MQTT publish, however it is sent as if it were the default unit of Celsius. Seems like the MQTT value should be saved in the default unit (Celsius) so the proper conversion is done at the end points.


#10

Any update on the status of this item?


#11

No change to the bug we discovered – there hasn’t been an update to our production systems since then, apologies… our developers have been focused on integrated solutions built on the Cayenne backbone like these.

I should mention that you might be interested in this post, specifically the part where we found you can send something like virtualWrite(13, 145, “null”, “myunit”) in order to publish a Value widget with a text label of “myunit”. This should allow you to send your temperature in F and get a “Fahrenheit” unit label by using a statement like:

virtualWrite(6, 82, "null", "Fahrenheit")

That should work around 95% of this issue, at a glance the only functionality you’d be losing would be to change the widget to C or K on the fly, since the system wouldn’t really know it is temperature data.