Just to clarify, z2m enables the parameter to be set on the device, so it’s still independent of the binding. It may even be beneficial since OH will never need to be aware of the offset.
Something else you may want to consider is firmware updates. You can update firmware with the Zigbee Binding using the openHAB console, but with z2m you just have to click an update button in the web interface.
Oh ! I need to check that out. I am just getting started with ZigBee.
Thanks for the hint.
You can set a filter on the persistence config to reduce that.
I also posted a tutorial recently with a JS Scripting transform you could use in a profile.
Nice one, I read that but did not implement it yet… until now.
That should “calm down” those:
I think this is a tutorial recently with a JS Scripting transform you could use in a profile you referred to.
Yes.
If you use a filter on the persistence config then the Item will still update with all those little changes but not all of them will be saved to the database.
With the transformation, the Item will only change if the delta between the last change and the new update is large enough, reducing the noise in the database and reducing the number of Item changes.
It all depends on how you use the Item as to which makes the most sense for any given case.
Personally, unless I have some sort of problem, I prefer to keep everything and deal with the noise after the fact so even that transform I posted in the tutorial I only used while debugging a problem in a rule and don’t use any more.
Yes, for now, I don’t have a real problem beside that the DB will fill up more for nothing. Since I persist a lot of data, I would rather try limiting.
I like the idea of the persistence filter and it is very simple. I am going for that now.
Since I never used ( - found a usage for…) transformation, I do note your tutorial though.
I have a few “unsolved use cases” where those may become the answer. Not asking yet since I did not do my research 
If you are using rrd4j it doesn’t matter. It’s a fixed size database which uses decimation to maintain that fixed size. As the data ages, a series of values (e.g. ten) get replaced with the average of those values. So the resolution of the data goes down as the data ages, but the database never grows no matter how much you write to it. It’s 738kB per Item whether there’s one change per hour or 1 change per second.
No I am using InfluxDB, which allows the same or to keep all the data.
InfluxDB is more convenient to me because I have a bunch of other sensors (not related to OH) that can also easy report to InfluxDB. The integration with Grafana is also a breeze…
I am not running InfluxDB in the OH Raspberry Pi though. I have the luxury of being able to run it in a small Kubernetes cluster that also takes care of backups, etc…
On item on my list though (I did not look into it yet) is how I could get some of the non OH data from InfluxDB back into OH.
I have for instance a small self made particle sensor that writes into InfluxDB. I know there is a binding to get the data from the cloud but since I have the data at hand, I would prefer to tap into mine
Yet another item on the todo but I am not worried too much about that one
I have to put some efforts into the WAF project first
There is no direct support for this. You have basically one overall option. You need a rule in OH or some external script that will poll InbfluxDB and push changes to OH through the OH REST API or some messaging protocol (e.g. MQTT).
It’ll be easier to get it from the cloud via the binding by a lot.
Time to get those sensor to “production” so I am now stopping my little experiment and thought I would share the current stand.
I reallly like those sensors. Are you will see below, the accuracy of the readings is good.
What those sensors are not great at is to consistently and accuratly follow rapid changes of temperature.
Other than that, they are great. I put only a reserve on the battery life with a “let’s see” for now but I saw no alarming sign yet.
I excluded some the chart the times where I moved things around or introduced new sensors.
While those charts look cool, they don’t speak all alone and when inspecting them, I had the context in mind (ie when I opened windows, etc…). The variance “explodes” no matter what when the temperature changes rapidly due to a window for instance. One of the reason is that the sensors were positioned next to each others and those closer to the WIndow hit the cold sooner. Moreover, those sensors report measurements when “they feel” like it and some rapid change may be transmitted sooner or later depending on the sensors.
After all, that was the idea of the thread: is is worth introducing offsets ?
I did 2 rounds of adjustments based on on the Variance:
Making those adjustments is ont simple and the fact that I have a fair amount of sensors did help.
I doubt this is reliably possible using 3 sensors…
Out of the 15 sensors tested, here are the offsets.:
grep -ohE "offset=\".*\"" * | sort -n
offset="-0.1 °C"
offset="-0.1 °C"
offset="-0.1 °C"
offset="-0.2 °C"
offset="-0.3 °C"
offset="-0.3 °C"
offset="-0.3 °C"
offset="0.0 °C"
offset="0.0 °C"
offset="0.0 °C"
offset="0.0 °C"
offset="0.0 °C"
offset="0.0 °C"
offset="0.1 °C"
offset="0.1 °C"
FYI: I introduced some 0.0 °C solely for the sake of this grep in order to find all th offsets easily. Those are useless mathematically otherwise.
It was a fun experiment, likely totally required as already mentioned but this kinda test is only doable easily before all the sensors are spread and installed (althought most can be detached easily as well).
It was a valuable learning to see how the sensors react compared to each others.
I mentioned another experiment here where I use a “Door / Window Contact” sensor for something else.
Due to the price and size of those sensors (snzb-02p, those without display), they may make also a solid base for home made sensors where up to 2 analog values need to be reported.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.