Blueline tweaks and improvements

[jbrzozoski]

• Fix a signed/unsigned bug in temperature reception
• Use a new linear estimate that fits my logged temperature data better
• Speed up ID guessing method by 64x by using a reverse CRC
• Improve ID guessing logic to also ensure that the "winning" ID isn't tied with another possibility
• Improve comments and documentation

Signed-off-by: Justin Brzozoski justin.brzozoski@gmail.com

[zuckschwerdt]

The temp conversion still looks a bit strange. I would expect something like tF = (X - 28) / 1.3 or tC = X / 2.333 - 30.
Can you record a rather high temperature to better see the scaling? Not sure if using an oven or hot-water is feasible, maybe a hair-dryer?

[jbrzozoski]

I got my hot air gun out and pushed it up to almost 50C. I backed off there since I was worried the heat was going to ruin the waterproofing. Still weirdly imperfect.

The transmitter design is based on a MSP430F1132, so I looked up the datasheet to see how it's internal temperature sensor works. Internally, it's a 10-bit ADC which can use different voltage references, but the recommended one for temperature reading would give these ADC values:

adc_reading = 1023 * (3.55*X + 986) / 1500

(3.55mV per degC, offset of 986mV at 0C, 1500mV reference)

I'm still pondering to try and get from this equation back to the numbers they report on the radio, but it's not a simple right-shift or anything else immediately obvious. They may have used a more precise external thermistor or something.

Here's the full table of data I've correlated between the radio and display:

recvd_temp,deg_C
44,-13
45,-12
54,-7
55,-7
56,-6
58,-5
60,-4
62,-3
64,-2
65,-2
69,0
70,1
71,1
72,2
73,2
75,3
78,5
81,6
100,14
102,15
107,17
114,19
115,20
116,20
117,20
119,21
122,23
124,23
125,24
126,24
127,25
128,25
129,25
131,26
134,28
137,29
139,30
140,30
143,31
144,32
145,32
146,33
147,33
148,34
151,35
155,37
161,40
166,42
169,44
175,47
177,48
179,49

[zuckschwerdt]

If the byte is a somewhat raw adc value then indeed a random slope and offset make sense. (And every hardware revision would now be in a tight spot to ensure protocol compatibility…)

A linear regression fits well, with an error-squares fit of 0.9984 (1=perfect) it is tC = 0.436*X - 30.36.
With 95% confidence the offset is -30.95 to -29.77, which would make 30 a good candidate, but the slope 0.4309 to 0.4409 has no obvious "round" number.

I guess your updated calculation fits the expected temperature range best then :)

[merbanan]

The device might transmit the raw temperature reading from the temperature sensor. Then you need a lookup table/function because temperature sensors are nonlinear. But I've only seen one sensor with that design.

[jbrzozoski]

The device might transmit the raw temperature reading from the temperature sensor. Then you need a lookup table/function because temperature sensors are nonlinear. But I've only seen one sensor with that design.

Whoever programmed this thing for Blueline has already proven they think "outside the box" with that weird payload-offset trick. :)

[bkenobi]

I'm not planning on using this meter's temperature for anything since I have a weather sattion, but wanted to point out that it appears to be offset from my Acurite 5n1 weather station is reporting by approximately 3°F. The outside temperature hasn't changed much in the last day so I don't know if this is always off by a constant.

[jbrzozoski]

I have no idea of the accuracy of the temperature sensor on this thing. If it's actually using the built-in sensor on the MSP430, it's mediocre-to-poor and will vary from one unit to another. All we can do is just replicate Blueline's math as closely as possible, and hope that they did a good job in designing the sensor and firmware on their side.

Anecdotally, after the adjustment in this pull request, my Blueline temperature readings line up within a degree of a LaCrosse outdoor thermometer I've been using for years.

[jbrzozoski]

Do you guys need anything else from me on this one?

[bkenobi]

I updated to the latest temperature correlation this morning. The attached plot shows the temperature reported by the power meter against my weather station (Acurite 5in1) reporting through rtl_433. I checked the temperatures earlier today when the module was reporting 47.98°F (8.9°C). The display unit showed 49F and the Acurite shows 50F. I assumed this was just an offset due to the different hardware in the weather station versus the power meter reader. However, looking at the temps this evening I see that the offset goes away and the two match really well although the BL display currently shows 43F and the rtl_433 code is calculating 41.7.

I'm not intending on using this as a primary weather station reading. The measurement is obviously not as high resolution. This is more to help inform in case a future update is considered.

[bkenobi]

I see this trend repeated daily where the power meter diverges from the weather station data starting in the morning ~10am until the afternoon ~2pm. I have only seen peak temperatures in the high 40's to low 50's. It is possible the difference is driven by location (weather station in sun, power meter in shade) but the rtl_433 data doesn't match the display by ~1.5°F currently.

[bkenobi]

I think there may be 2 reasons why my weather station and power meter don't show the same temperature. First, the weather station is located in the sun (as it should be) but the power meter is located on the north facing side of my house which gets no sun. The shade will likely be cooler than in the open exposed to solar radiation.

Second, the peak temperatures I am seeing right now are exactly where the linear approximation breaks down. As you can see from the plot of the recvd_tmp (in degF) versus output temp for both the raw converted data you posted and the equation, there is an error that happens to peak at 39°F of 2.4°F. I will look at this going forward, but I'm wondering if a table lookup/interpolation would be more accurate if not too difficult. As stated before, since this isn't a weather station, perhaps the accuracy is not something anyone will care about.

[bkenobi]

This device was updated recently (Oct 29). I had not updated my code since early this year (January or February) so when I updated I expected a few tweaks. I don't know if it's documented and I missed it, but the device name that is published in MQTT has been altered so my Node-Red flow does not work anymore. It should be an easy fix as it appears that the old name:
Blueline_PowerCost_Monitor

has been changed to:
Blueline-PowerCost

This is a subtle difference but might cause some issues for anyone who updates and finds their old HA setup no longer works as they expect. Not a complaint by any means, just pointing out that if I missed the note in the documentation perhaps others will too.