Every state that can be set through the HTTP interface (CGI commands) can now also be set with an MQTT update. But currently, there are no system events published through the MQTT interface - this will change with the next release.
But you can already use the alarm server to be notified every time an alarm event is triggered. The alarm server will send an HTTP GET request to a webhook that has to be provided by OpenHAB. The easiest way to do this is to use the Camera Binding by @matt1:
You are right features/nightvision/currentbrightness is a topic that does not yet work as expected. The value for this light sensor is updated every time your camera restarts. But we do not receive an update every time the sensor readout changes. We will have to implement a trigger that pushes an update in a set interval for this to work with MQTT. Another example would be a topic that sends out a base64 encoded snapshot.
With this update we fully implemented only the first Type of MQTT topic:
Topics that are updated by user interaction
Topics that are updated by system events
Topics that have to be updated in a preset interval
The INSTAR MQTT service is now regularly available via the System/Update menu and some improvements/bugfixes have been added:
Further MQTT Topics added (e.g. for step-by-step control of the camera’s P&T)
User logins are now excluded from MQTT state topics (can only be set via command topic)
All special characters, which are allowed for the camera login, can now also be used for MQTT.
The ports used for the MQTT service were changed to the default 1883/8883
In the beta version, no distinction was made between “local” and “all” in topics. The first now only addresses the camera on which the broker is running and the latter addresses all cameras in the MQTT network
The use of own SSL certificates for the MQTT service was simplified. We already have a guide for self-signed certs online, for CA Certs (Let’s Encrypt) will follow shortly. But I did not yet try to get this to work with OH. If someone has experience using self-signed certs for the MQTT Binding - please let me know In case of Node-RED you simply upload the public key.
I received a couple of messages that the OpenHAB Camera Binding wasn’t working. Especially the snapshot preview did not show up. I just retested it by doing a fresh setup according to the user guide - and here are a few things that you can check if things go wrong.
Type number : alarmTriggered "Alarm triggered" [ stateTopic="instar/10D1DC21AABB/status/alarm/triggered", transformationPattern="JSONPATH:$.val", qos=1 ]
Number Kamera_EG_alarmTriggered "Alarm ausgelöst [%s]" (gCamera_Eingang) {channel="mqtt:topic:localhost:10D1DC21AABB:alarmTriggered"}
What is working - but:
Kamera_EG_alarmTriggered changed from 6 to 2
Which means, openHAB is only detecting a triggered alarm on change, not on update.
So if the same area is triggered two times or more often only the first alarm is showing up, until another area is triggered.
Same behavior if i use “String” instead of “Number”.
It is working.
Reset the value within openHAB, no need to do the reset within the camera:
rule "Kamera - Eingang/Alarm ausgelöst"
when
Item Kamera_EG_alarmTriggered changed
then
if (Kamera_EG_alarmTriggered.state != 0){Kamera_EG_alarmTriggered.sendCommand(0)}
end
At the moment i don´t know how clever it is, to let the Item reset itself…
There are other home automation systems - like Loxone - where you can choose between regular commands and what they call “pulses”. The latter lets everything drop back to idle automatically. It is very handy.
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!