Generic sensor processing code

General
41

Try

const table = [
  {id: '245', tag: "A"},
  {id: '1066', tag: "B"},
  {id: '1878', tag: "C"},
  {id: '9170', tag: "D"},
  {id: '11106', tag: "E"},
  {id: '1294', tag: "F"},
  {id: '10160', tag: "G"},
]
const topicArray = msg.topic.split("/")
const id = topicArray[topicArray.length - 1]

msg.payload.tag = table.filter(table => table.id == id)[0].tag;

let newmsg = {topic: "Acurite-Tower/"  + id}
newmsg.payload = [{tempF: msg.payload.tempF, humidity: msg.payload.humidity, battery_ok: msg.payload.battery_ok}, {location: msg.payload.tag}];

return [msg, newmsg];
42

Sorry, I am away at the moment and not able to contribute.

43

image
That seems to have worked, thanks! I'll see if I can get that to log the data in influx next.

44

And as Colin had suggested, by formatting the data that way when outputting to Influx it works as expected. I end up with tempF, humidity, and battery_ok as fields and location as a tag. Much appreciated!

45

A couple of points you may wish to consider;

  • Not sure how unique the ID codes are so if your 433 reception is anything like mine you are receiving data from umpteen devices in the neighbourhood, you may wish to also check the model details (I do)
  • The ID can change when the batteries in a device are replaced so I keep a record of all IDs and models received so that I can find the new ID
46

The model of sensor im using (592TXR) has a fixed ID which doesn't change with battery swap. I had another one (609TXR i believe) that would change whenever you turned your back so I'm not using that one. These 592 work well and seem to have a very large pool of ID so, while it is technically possible another could have the same ID, it seems unlikely. One of mine is 11106 so there are at least 11,000 possible ID's in the wild.

I've been using rtl_433 to determine the ID and writing it on the back with a sharpie for future reference.

47

I just tested what would happen if I had a sensor that wasn't defined in the list show up and it seems to crash the function ungracefully. I was just thinking it might be nice to trap the error and inform what ID was found instead of giving a stream of ugly error messages that mean nothing.

const table = [
  {id: '245', tag: "A"},
  {id: '1066', tag: "B"},
  {id: '1878', tag: "C"},
  {id: '9170', tag: "D"},
  {id: '11106', tag: "E"},
  {id: '1294', tag: "F"},
  {id: '10160', tag: "G"},
]
const id = msg.payload.id;

msg.payload.tag = table.filter(table => table.id == id)[0].tag;

if (msg.payload.hasOwnProperty("tag"))
{
    let newmsg = {topic: "Acurite-Tower/"  + id}
    newmsg.payload = 
            [{
                tempF: msg.payload.tempF, 
                humidity: msg.payload.humidity, 
                moisture: msg.payload.moisture, 
                battery_ok: msg.payload.battery_ok, 
                id: msg.payload.id
            }, 
            {
                location: msg.payload.tag
            }];

    return newmsg;
}
else
{
    node.warn("Acurite-Tower ID not found in list: " + id)
}

Line 12 causes an error because the tag doesn't exist for a new sensor ID. In C I would use a try...catch type approach where if it failed it would simply kick over to the alternate code. I'm not a JS coder, so I'm searching now to see if something similar exists.

EDIT:
Found a solution using try...catch that works great. I'll leave this open in case there are other related questions, but right now it looks like this is going to work!

48

I can start a new thread if more appropriate.

Now that I have all of my sensors being detected and collected correctly, I was hoping to calibrate them. The temperature and humidity show a similar trend, but they seem to have an offset. I was thinking the best option would be to track the delta from the mean of all averages. I could do this by downloading all data to Excel, but I thought it would be a good learning exercise to process on the fly. My thought was to run a query to find the mean value of all sensors over the last 1, 5, or 10 minutes and save the delta from average to each sensor.

My query works in the influx command line tool.

> SELECT mean("tempF") FROM "Acurite-Tower" WHERE time > now()-1m
name: Acurite-Tower
time                           mean
----                           ----
2022-04-10T03:45:42.292890538Z 38.768

This should work if I run this in an InfluxDB node but I believe that would require joining the results back in. And based on the learnings from this thread, I gather that's not ideal. What would be the preferred method for running a query and then adding the result back to the same message?

49

Would it not be better to individually calibrate the sensors, and apply that calibration when you read them?

50

That is what I intended to do. I need to determine an offset of some kind to calibrate each sensor. But I was simply suggesting that using the average of all sensors would be a good stand-in for coming up with a more accurate reading. If calculating the average temperature of the sensors and then using that to determine the variation is difficult, I can do it manually. I was planning on just coming up with a curve of offsets for each sensor during a day or two so that I could see what it looked like over time and determine a single value or a curve that would be hard coded. This would basically just be used to determine the calibration.

As I said, I could do the same by downloading all the data and doing the same thing in Excel but it seemed like an opportunity to learn how to do it with NR. If this is more complicated/not feasible, I'll just do it manually though.

I can also just put the sensors in a few fixed environments (freezer, fridge, basement, some kind of higher temp environment) for a period to stabilize to calibrate at those temps/humidity.

51

What sort of sensors are they? Usually all you should need is a fixed offset for each sensor to take out the error, which is presumably only fractions of a degree. A batch of devices might easily all show a similar offset so an average is not what you want.

52

I have a number of Acurite 592TXR tower sensors. These are 433MHz transmitters that provide temperature and humidity for indoor/outdoor use (not in direct sun/rain though). They are a good combination of price, size, availability, and accuracy. Most importantly for me, they are easily compatible with SDR + rtl_433.

The specs claim Ā±2Ā°F and Ā±3-5% RH (depending on temperature range). Since I'm most interested in mold issues currently, if the RH is above 40%, it's in a danger zone. I'm really just trying to find a way to compare sensors to determine if the conditions inside and outside are sufficiently different to make turning on a ventilation fan appropriate. My current setup uses multiple DHT11 sensors to compare the inside and outside temp/RH to determine when to ventilate. For the DHT11, I did as you suggested and found an offset for temp and RH for each sensor which has worked well.

For reference, I was initially planning on using BME280 extended to the appropriate location for detection using RJ11 (4 conductor) wire. I found that the transmissions were not reliable with longer wire runs so eliminated that as an option. I moved to Acurite primarily because they seemed fairly accurate and the battery lasts for a long time so I would only have to enter the attic very rarely. I could also modify them to run off of a AC/DC adapter fairly easily meaning never changing batteries.

53

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.