Hi, I am receiving temperature readings from a lacrosse device via a jee link, to mqtt. I get that info via this in my items file:
String Cellar_Temp_Reading “Cellar Temp [%s]” (all) {mqtt="<[hammy:/sensors:state:default"}
Here is an example what I receive from the sensor.
Cellar_Temp_Reading state updated to 2015-08-25 18:35:40 D:3C: 13.8:99
The line above breaks down as follows:
timestamp, then D: indicates device number (e.g… 3C), then the temperature (13.8). I think the last field will be battery power, but I’m just not sure at this time.
I would like to set up openhab so i can get push notifications whenever the temperature is out of a defined range, and also whenever I haven’t received a reading in say 75 minutes.
Should I be doing this will rules, watching for this reading to change? Any other suggestions?
It would be preferable to get this parsed before it enters MQTT, so the other subscribers can see the data as it’s separate components. That said, the fields can be extracted/transformed in openHAB via a Rule, if it’s not possible/practical to parse it up before it enters MQTT.
The REGEX Transformation engine can pull that apart. Internally, openHAB’s REGEX Transform uses Java’s Pattern class, which has format options needed.
For example, the pattern to extract the temperature (rough, very rough) will look like:
.*[ ]([0-9\\.]+):[0-9]+
which you can extract inside a Rule using something akin to:
var String r = Cellar_Temp_Reading.state as StringType
var long temp = Long::parseLong(transform("REGEX", ".*[ ]([0-9\\.]+):[0-9]+", r))
You can then push it back to any other items that you want, for display & rules (etc), using postUpdate()
Correct. If you publish it into MQTT the structured form, as a series of related topics, life is a lot easier for all the folks who may want to use the data (including openHAB)
That’s what I meant by:
The specific topic-heirarchy used will come down to preference. Ones based upon physical device-id’s break over time as devices are replaced, upgraded (etc).
Initially it won’t be a problem, but I’ve substituted devices over the lifetime of my system, and it’s always been painful to rewrite Rules (etc) when the target system uses some id-based naming model, instead of using either a guid (neutral, but not self-describing) or user-specified naming model.
Obviously not as much an issue for openHAB, since Items are that name ↔ id mapping, but for other consumers of the MQTT data it could be an issue.
Neither model is particularly wrong, but they each have pros and cons.
btw, if you end up doing the extraction in a Rule and you’re only extracting one bit then using openHAB’s transform(...) will be fine. For multiple extractions consider using Java’s Pattern/Matcher classes directly (with multiple captures/groups defined) as it’s more efficient than multiple transform('REGEX', ...) calls.
Something as seemingly simple as integrating in temperature sensors really
has some layers to think about.
The next issue is the sensor seems to spit out sporadic seemingly invalid
results. The cellar is around 12.8 degrees celcius, but some times a 26+
will get spit out, or something even -ve. I was going to scrub these
readings within a rule, but your comments have given me pause. If my
python script which reads the serial port of the RF receiver for the
sensors is converting device id’s to physical location topics, then maybe I
should just do the work there to eliminate ‘bad reads’.
Another option I suppose would be to do the data validation within openhab,
and republish those results on mqtt.
Based on your experience, what do you think will work best as I scale up
the number of sensors, and then live through some upgrade cycles, etc.
I like to do that work as close to the sensor as possible. You’ve got more data to work, since your rate of sampling is often more frequent than the publication rate, and with more data comes an improved ability to filter out irregularities.
If you have processing power there, and the ability to keep a few cycles of data in memory, then it’s a model that scales out as you create new devices at the edge… it continues to works even when openHAB Rule execution gets jacked up.
At the small scale, I have a Spark Core running as a temperature sensor that’s doing just that (albeit not over MQTT atm). At the medium scale, I have a Raspberry Pi that’s capturing 30+ channels of energy + temperature data from the house. All these things purpose-built devices operate autonomously, along with stuff like the Alarm System (etc). openHAB, and previously MiOS/Vera, just observe and/or influence the operation of the “thing” under control.
That said, you won’t get everything.
I worked on a project where we had GPS information coming into a device. We had a 10-15 minute period (1 minute samples IIRC) where the device thought it was in the Pacific ocean… when it was just outside in the parking lot. No amount of light-weight/on-device filtering would fix that…
