Issue with temperature units
-
I have seen the same issue with 1.4 when using DHT or Dallas ...
I have try to clean EEPROM, change on Vera from metric to Imperial and back to metric without any succes...
So hardcode temperature in C was the solution for me... -
I have the same problem with DallasSensor
Startup says:
sensor started, id 2 send: 2-2-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4 send: 2-2-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0 read: 0-0-2 s=255,c=3,t=6,pt=0,l=2:M <<<==== Metric <<< send: 2-2-0-0 s=255,c=3,t=11,pt=0,l=17,st=ok:Light+Temp Sensor send: 2-2-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0 send: 2-2-0-0 s=0,c=0,t=16,pt=0,l=3,st=ok:1.4And I trace:
Serial.println(gw.getConfig().isMetric);which output 0, not 1
Switching to Imperial I get:
sensor started, id 2 send: 2-2-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4 send: 2-2-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0 read: 0-0-2 s=255,c=3,t=6,pt=0,l=2:I <<<==== Imperial <<< send: 2-2-0-0 s=255,c=3,t=11,pt=0,l=17,st=ok:Light+Temp Sensorand the trace says 0 as expected.
Then I tried to trace in MySensors.cpp and added (not workin though ;) ):
} else if (type == I_CONFIG) { // Pick up configuration from controller (currently only metric/imperial) // and store it in eeprom if changed isMetric = msg.getByte() == 'M' ; debug(PSTR("isMetric=%s\n"), isMetric); debug(PSTR("cc.isMetric=%s\n"), cc.isMetric); if (cc.isMetric != isMetric) {But then it started to work :D
Removed the lines above and the problem is back....so something there...
Don't have time right now to test.... -
Yes for some strange reason :)
However I used %s and not %d in the debug but have now used %d as below} else if (type == I_CONFIG) { // Pick up configuration from controller (currently only metric/imperial) // and store it in eeprom if changed isMetric = msg.getByte() == 'M' ; debug(PSTR("isMetric=%d\n"), isMetric); debug(PSTR("cc.isMetric=%d\n"), cc.isMetric); if (cc.isMetric != isMetric) { cc.isMetric = isMetric; debug(PSTR("Updating EEPROM\n")); debug(PSTR("isMetric=%d\n"), isMetric); debug(PSTR("cc.isMetric=%d\n"), cc.isMetric); eeprom_write_byte((uint8_t*)EEPROM_CONTROLLER_CONFIG_ADDRESS, isMetric); //eeprom_write_block((const void*)&cc, (uint8_t*)EEPROM_CONTROLLER_CONFIG_ADDRESS, sizeof(ControllerConfig)); }Gives the output
sensor started, id 2 send: 2-2-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4 send: 2-2-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0 read: 0-0-2 s=255,c=3,t=6,pt=0,l=2:M isMetric=0 cc.isMetric=1 Updating EEPROM isMetric=0 cc.isMetric=0So it seems that "metric" flag is not unpacked correctly, or?
-
@jocke4u said:
l=2:M
I find it strange that length is reported as 2 while only a single character seems to be sent. The protocol version 1.4 is correctly reported as length 3.
uint8_t MyMessage::getByte() const { if (miGetPayloadType() == P_BYTE) { return data[0]; } else if (miGetPayloadType() == P_STRING) { return atoi(data); } else { return 0; } }Payload type will be P_STRING when controller sends the data. Yes, why does it get size 2?!
-
uint8_t MyMessage::getByte() const { if (miGetPayloadType() == P_BYTE) { return data[0]; } else if (miGetPayloadType() == P_STRING) { return atoi(data); } else { return 0; } }Payload type will be P_STRING when controller sends the data. Yes, why does it get size 2?!
-
Hmm.. we should probably not use atoi in case of String. Payload type should not matter in the getByte.
-
Yep, this is a bug.
I've also found that the newline character is included and transmitted on all outgoing messages from gateway! So payload length 2 was correct, and wrong ;)
How is it possible no one has seen this before (me included)?
-
Hmmm... how can one override this statement to be METRIC?
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?TemperatureSensors.getTempCByIndex(CHILD_ID_TEMPERATURE_FIRST+i):TemperatureSensors.getTempFByIndex(CHILD_ID_TEMPERATURE_FIRST+i)) * 10.)) / 10.; -
hello,
I must confess I have not read this thread completely. Too much for my bad english)
We try MySensors support for FHEM (www.fhem.de) to impementieren. I noticed that when the I_CONFIG message is answered correctly with 'M' for metric, then the sensor sends in Imperial. Is not surprising, everything is interpreted as a string from Gateway, but also byte checked. My solution proposal: In MySensors.cpp:
(isMetric = msg.getString()[0] == 'M' ; instead of isMetric = msg.getByte() == 'M' ;)} else if (type == I_CONFIG) { // Pick up configuration from controller (currently only metric/imperial) // and store it in eeprom if changed //isMetric = msg.getByte() == 'M' ; isMetric = msg.getString()[0] == 'M' ; if (cc.isMetric != isMetric) { cc.isMetric = isMetric; eeprom_write_byte((uint8_t*)EEPROM_CONTROLLER_CONFIG_ADDRESS, isMetric); //eeprom_write_block((const void*)&cc, (uint8_t*)EEPROM_CONTROLLER_CONFIG_ADDRESS, sizeof(ControllerConfig)); } } else if (type == I_CHILDREN) {Best regards,
Alexander
-
Thanks for the quick reply.
I've downloaded the source here: https://github.com/mysensors/CodeBender/blob/master/MySensor.cpp
Since it is still old.Now I see that https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/MySensor.cpp would be better.
-
Oh.. you downloaded from codebender. That explains it.
Unfortunately it's still a bit too messy to update the public libraries over there (have to contact the codebender-people every time). Nowadays we keep a copy among in the MySensors-account which gets copied if you clone one of the examples.
Github always contains the latest.
-
My mistake. Was unfortunately cost few hours time for the search. For that I have won something overview in MySensors Code :)
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login