It sounds like you are heading down a good path. I just wanted to add a couple of comments.
Option 1: This is the best approach when the publisher misuses MQTT by sending large JSON messages instead of publishing to separate topics. One of the guiding principles of MQTT is “thou shall not impose work on your subscribers.” Requiring subscribers to receive and parse a JSON string is an imposition. Remember, MQTT was designed to work with underpowered microcontrollers in a spotty networking environment.
Option 2: This won’t work, as you surmise.
Option 3: This is a last option when Option 1 and Option 4 are not possible. Option 1 can sometimes not be possible if the JSON sent includes a not-fixed size array. The JSONPATH transform is not flexible enough to handle that case.
Option 3a: A Script transformation could be used instead of a Rule in some cases.
Option 0: This is the more MQTT way to solve this problem. zigbee2mqtt should not impose work on it’s subscribers.
So the “right way”, from an MQTT perspective is Option 0. Failing that, Option 1 is next best followed by one of the Option 3s.
Yes, I also noticed that when I tried to implement it.
Yes, this is not ideal, but I’m thankful that someone actually took the time to program zigbee2mqtt to read the FP1 sensor in general, and its zones in particular. I’m not sure why they chose this path, but I assume it was easier to implement and/or a way of avoiding other pitfalls.
I now realized that they not only squeezed the actions recorded in up to ten zones into a single mqtt topic but also two types of actions/status that could have been much more conveniently in two separate switch topics: leave/enter and occupied/unoccupied. Unless I’m misunderstanding how these work, these pairs are about quite different things: the leave or enter event triggers every time someone leaves or enters the zone in question, i.e. it signals an event, and occupied/unoccupied topic is about the state of the zone.
So, I’m not sure what might be the benefits of putting all of that into a single topic, but maybe there is something about having one topic instead of twenty (10 zones x 2 topics). But even two topics instead of one would have made more sense.
Yes, so maybe another explanation could be that zigbee2mqtt actually has some built-in magic specialized on modifying the default topics, e.g. by splitting up a given topic into multiple topics or sub-topics or something, but I didn’t want to dig into that. Rather took the opportunity to learn more about OH.
For now, I’m wondering how I can use maps in OH so that certain inputs are simply ignored. I have created two maps:
exit-enter.map:
enter=1
leave=-1
and occupied.map:
unoccupied=0
occupied=1
believing that each map will ignore the states that it can’t map, but this is apparently not the case:
2024-01-19 20:12:02.716 [WARN ] [al.profiles.MapTransformationProfile] - Could not transform state 'occupied' with function 'enter-exit.map' and format '%s'
So, I take it that a map must cover all possible input values. So, is there a way of telling it “if this value comes in, do nothing”, i.e. not update to null or anything, just keep the previous value?
A default value can be provided if no matching entry is found by using “=value” syntax. Defining this default value using _source_ would then return the non transformed input string.
OK, so if that page is documenting all possibilities, then the answer is: no, it’s not possible. I’ll have to either use a rule or figure out how to do it in zigbee2mqtt…
I’m not sure about your interpretation of these actions as independent pairs. I think they’re an ordered sequence, because only one can be possible at any time:
enter → occupied → leave → unoccupied → enter → etc.
If there are two people in the room and one person leaves, the FP1 won’t change to leave, because the room is still occupied. And if the other person comes back, it shouldn’t trigger enter, because the room is already occupied. When both people exit, it changes to leave and then unoccupied.
That’s exactly what you want from an automation perspective: turn on the lights when two people enter a room, but don’t turn off the lights when one person leaves. Then turn off the light when the second person leaves.
I might be wrong about this. If you haven’t already done so, the easy way to test would be to carry out the scenario above with two people and see whether or not the enter/leave events are triggered.
If my interpretation is correct, 10 separate regions would be best. As it is, if multiple regions change at the same time it’s going to spam a lot of state changes right on top of each other. They shouldn’t ever conflict, but state changes could get missed. You might want to file a change request with Zigbee2mqtt.
In any case, I’ll be curious to hear how well it works for you. I’ve been thinking about trying out a presence sensor.
I haven’t tested it, but I think you’re right. Thanks for pointing this out.
Yes, that’s exactly the issue I’m trying to solve. And yes, 10 regions it is, not 20. In fact, 3 is enough for me, but the sensor can handle up to 10.
I can’t seem to figure this out in zigbee2mqtt, but I think I should be able to get it to work in OH, now that I’m no longer trying to split leave/enter from occupied/unoccupied). I’m now using region_1_(\w+), region_2_(\w+), and region_3_(\w+) in the profile for three items.
Actually, I thought that would work, but it looks like I have the same problem as with the maps above: if the regex captures nothing (because the event concerned a differemnt region), the item state becomes empty (not NULL), so it looks like the issue can’t be solved with transformations. I’ll have to use rules after all…
Interestingly, if you weren’t using regions then your initial thought about separate enter/leave and occupied/unoccupied pairs is correct: they’re two different reports. The way I read it, when regions were added to Zigbee2mqtt, they were combined to take advantage of the faster triggering of enter/leave.
On a semi-related note, this conversation prompted me to try out the new Sonoff SNZB-06P sensors and I just received them today. They’re much less expensive than the FP1, but also much less flexible/tunable.
What’s nice about the regions in your FP1 is that you could omit a problem area such as a fan or curtain. With the Sonoff, you can only set the sensitivity distance (2.5m, 3.5m, 4m).
I have now permanently installed it in the kitchen but so far I’m not too impressed with the performance (considering the price). I may still have to tweak things (i.e. the zone confuguration), but I suspect the main problem is that the sensor simply doesn’t cover parts of the area where the kitchen counter is. I had to mount it in the corner (because it doesn’t cover the whole 180° to put it on a flat wall) but that may have entailed that it doesn’t reach all the way till the next corner.
I also just noticed that my OH3 container was using a lot of CPU due to some java issue, so that may also have been responsible for some hickups, in particular long delays until the lights actually go on.
A third thing to investigate when I have time is whether some state changes in the action topic happen so fast that OH misses some “enter” events sometimes. That is clearly the big disadvantage (I would actually say: a design flaw) in how this was implemented in zigbee2mqtt. I have not been able to find a way to make zigbee2mqtt report each zone in a different topic.
Yes, these are the pages I have been using. Could not have done it without them.
The other day, watched an excellent review video comparing a number of presence sensors (I don’t think that one was among them, though) and noted two that I’ll probably try out: the Hi-Link HLK-LD2410 and the Tuya ZY-M100-S. The first one is ultra cheap and the second one is reasonably priced with basic functionality. The Tuya is probably the easiest solution for simple setups like in the toilet and bathroom, but I already have a working setup with IR sensors and door sensors in these rooms. The Hi-Link looks like it needs a lot of fiddling and tweaking and I don’t really want to spend my time with that at the moment. I suspect there will be big improvements as well as price drops in this market in the coming months and years, so I’m not in a hurry.
Set a QOS of 2 on both the zigbee2mqtt (if possible) side and on the OH side. That ensures the message gets delivered instead of dropped if too many happen at the same time. It also ensures that each message is only delivered one time. If you don’t mind multiple reports of the same message set the QOS to 1. Default is 0 which is kind of a fire and forget with no guarantee that the message is received by the subscriber.
