Issue with temperature units

hek

Are you saying adding debug prints makes it work?

jocke4u

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=0

So it seems that "metric" flag is not unpacked correctly, or?

Yveaux

@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.

hek

@Yveaux

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?!

hek

Hmm.. we should probably not use atoi in case of String. Payload type should not matter in the getByte.

hek

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)?

jocke4u

Sounds good anyway....one bug less :)
I just setup a sensor with DHT22/AM2302 and get the same results here.

hek

Fix checked in. I'm creating a more comprehensive release note in the 1.4 thread.

Yveaux

@hek said:

How is it possible no one has seen this before (me included)?

At least I saw it ;-)
I personally tend to read over all the details in the serial api... This time I noticed.

Be glad you nailed it!

jocke4u

Thanks @hek and @Yveaux I can confirm it's working on both Dallas sensor and DHT22.
Great support!!

Nuubi

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.;

hexenmeister

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

hek

Welcome @hexenmeister!

What version of MySensors library did you download? The current version in gihub/master already has getString()[0].

hexenmeister

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.

hek

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.

hexenmeister

My mistake. Was unfortunately cost few hours time for the search. For that I have won something overview in MySensors Code :)

Issue with temperature units

11

11.7k

11.2k

113.1k