MQTT Full HD Camera for OpenHAB

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. :roll_eyes:
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… :confused:

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.

  1. I think a client should be able to publish retained and not retained messages (topics) to the broker. Retained means, the broker hold the value not just for one client but as state for all clients and for all the time. All clients, also them connecting later to the broker, can see the last value. In PaperUI, I can configure the retained-flag on every channel -> topic. Also wenn I use other MQTT Clients like pubsubclient on arduino or what else.
  2. Is “alarm triggered” a state or an event? I think it is an event. States should be retained, events not (Its my opinion). Wenn I connect with a brand new client to the broker and there is a topic alarm/triggeres with value 1, what will it say to me? Is this a current message? Is it years old?

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.

1 Like

@danil - The update just arrived and can be installed via the camera webUI:

INSTAR Full HD WebUI Update

What’s new in version 3.1 (347) ?

  • MQTT adapter was revised
    • MQTT prefix and camera ID can now be set by the user
    • After the alarm is triggered (after 5s), the alarm server automatically returns to an idle state (with payload 0).
    • The camera now leaves a Last-Will Topic with your MQTT broker. Should the camera lose connection to the broker, the broker will send the LWT to all subscribers.
    • The device ID with which the camera registers with the broker was previously generated randomly. As a result, certain smarthome systems have detected the camera as a new device after each reboot. The Device ID is set equal to the Camera ID (settable in the MQTT menu).
    • General bug fixes and improvements
  • Alexa Support - INSTAR Cloud Skill now available with which you can play recordings from your cloud account as well as directly accessing your individual cameras and have Alexa control your camera.
  • IFTTT Support - On the IFTTT Platform, we provided an INSTAR Applet. The INSTAR Applets provides a way for you to control some settings of your INSTAR Camera as well as your INSTAR Cloud account through IFTTT scripts.
  • In order to use Alexa and IFTTT you have to create a free INSTAR Cloud account. Sign-up NOW and enjoy all paid features for 30 days without any costs.
  • For Alexa and IFTTT a new sub-category called Smarthome has been added to your cameras webUI. Alarm server and MQTT settings have been moved to Smarthome.
  • General bug fixes and improvements
2 Likes