I think there is still a problem if i need to restart OH.
If OH restarts, it fetches all values from the cam and might trigger the non resetted alarm from the camera.
Can’t check this right now…
I think there is still a problem if i need to restart OH.
If OH restarts, it fetches all values from the cam and might trigger the non resetted alarm from the camera.
Can’t check this right now…
Ok, If you restart regularly this would be an issue. In this case, you have to update the state on your camera:
MQTT: instar/local/alarm/triggered/raw
payload 0
How do you know that?
Default events.log
behaviour is to not log update events where the state is not changed.
A quick way to be sure is to have a rule triggered on Item update, and log the event.
Ok, will try this in the evening…
Restarting openhab might still trigger a wrong alert.
received update
is working fine, restarting OH triggers an alert - even if i persist the item.
It’s not really clear what you are doing now.
You’ve changed your rule to trigger from received update
?
And that now works as you want? i.e. two successive triggers from zone 2 or whatever do your thing.
But you’re left with a false report at each reboot? I would guess that is because the device is “refreshed” at binding start and you get an update.
A trick here is probably NOT to persist and restore at all.
Then modify your rule to see if previousState
was NULL - if it was, you have that initial refresh event which you can choose to ignore.
I am using “received update” now instead of doing a reset an using “changed” and it works as wanted.
And yes, there is a false report at reboot.
Without persisting the item it changes from NULL to some state.
Never used “previousState” in a rule - i have to Google it and will give it a try - sounds like a good trick, thank you!
It’s an implicit variable, made available from rule triggering event. Not to be confused with myItem.previousState()
method, which is persistence based.
I tried a lot, but it looks like
if (previousState == NULL) {return;}
is only working with “changed” not with “received update”.
Thank you anyway.
I’d completely forgotten that, and it is a pain to deal with.
We cannot use persistence either, because that won’t persist NULL.
I can think of methods involving treating the MQTT messages as events, either trigger channels or commands, but they’re no less complicated than a simpler way that keeps your MQTT config the same.
Create a shadow Item, not linked to anything else.
In your rule, check its state for NULL before “doing whatever”.
Before exiting the rule, postUpdate the “real” Item state to the shadow, ready for next time.
(really an on/off record would, but this is easy)
You could do something similar with a global variable instead of a shadow Item, if wanted.
If you’r going to have several similar camera triggers, you can manage this with a group trigger rule and a set of shadows managed by “associated items” naming convention. Or use a global variable Map instead.
That´s too much work-around…
It´s gonna be easier to reset the value within the camera, that minimizes at last a false trigger.
Yes, it’s a terrible chore to create one Item and two lines of rule code.
rule "Kamera - Eingang/Alarm ausgelöst"
when
Item Kamera_EG_alarmTriggered changed
then
if (Kamera_EG_alarmTriggered.state != 0) {Kamera_EG_alarmTriggered.sendCommand(0)}
if (previousState != 0) {return;}
end
Still two lines of code, but no extra item…
Hi @mpol,
I’ve configured MQTT and I just wounder why you (INSTAR) publishing alarm/triggered as an retained topic? So every connect to the broker tigger an alarm…
The next thing is… the camera has lost the mqtt connection, so no status updates are send to the broker and no commands are registered from the camera. So my question, is there a LWL Topic?
Having written MQTT bindings before I know what is possible and how mqtt works in depth…
I don’t believe it is possible to choose what is and what is not retained, probably only possible if a device connects twice to the broker with different connection settings. I could be wrong but it would increase the complexity and resources on the camera. So having all messages as retained is IMHO correct. When openhab connects to the broker it can choose to have a ‘clean session’ where it does not get sent the previous saved states, or to get sent all the states by not using a clean session. Not sure if the mqtt binding gives this option but it is a solution and is explained here.
https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/
A dedicated binding that receives all the states and can then filter through and make smart choices based on what the author has written is the better way forward. By not having a dedicated binding and by using a generic method, there is a trade off.
Hi @matt1,
thank you for your detailed answer.
The part with the persistent sessions was unknown for me and interesting. So I have to read much more about MQTT to full (better) understand (specifically the part with qos).
I’ve not found them…
After a short reading your linked article, I think it is linked with qos rather than retained?
So I’m not sure what exactly is the expected behavior.
Hm, I don’t know it, but its my feeling the alarm triggered event should not be retained…
Daniel
Sorry its been a long day and since I have not used the camera in this way I have not fully thought through the issue and should not comment further other than to say point 2 sounds reasonable and there is probably a work around that could be done in your rules.
Correct (except the last sentence is not always true) for what I would call “retained messages”, there are also “retained sessions” which are totally different. If a client connects with a “clean session” flag set, then the broker will not send the retained messages through to that client. A retained session works as you have described, but if a client with a retained session drops out and reconnects, then only the new messages missed are sent and not the whole set of retained messages. Very handy and flexible set of options.
If Openhab chose to use a clean session instead of a retained session, then all retained messages are not sent through and this would be an issue for updating any status controls like the position of the motion alarm enabled switch as you can not pick and choose what messages get processed unless you do this in a custom binding. At a session level it is all, or none of the retained messages. I guess my previous post was not helpful and I had not thought it through all the way as it would solve the event issue you outline but cause issues for your states.
Hey Danil,
currently, all our STATUS topics are retained, while all COMMAND topics are not. The idea is to make sure that you always get the complete picture of what is going on with your camera when you connect to your MQTT network. Especially, important for UI / Dashboard Apps.
For the alarm event - we don’t see it as just a trigger but also a state. E.g. you receive a notification that an alarm was triggered and you can check your dashboard to see the last trigger.
We are now considering making the retained
flag for STATUS topics optional and we will also check if automatically dropping the alarm trigger back to a 0
value after an alarm event is pratical.
We will roll out an update after testing those options.
Noted - a Last Will Topic will be added.
@danil - The update just arrived and can be installed via the camera webUI:
0
).