MQTT Full HD Camera for OpenHAB

There are a lot of topics i really don´t need :wink:

So a general question: What is already implementet?

relay - on/off/state
nightvision - state (kind of brightness sensor)
audioalrm, pir, motion detector - state

Is there a way to see if they are triggerd or what value they currently have?

I found this one:


which looks like a brightness sensor, but it did not change for last 4 hours…

Thank you very much…

Hey @Dragonfly,

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:

  1. Topics that are updated by user interaction
  2. Topics that are updated by system events
  3. Topics that have to be updated in a preset interval

About the JSON transformation issue:

Have you tried working with raw topics? When you add \raw at the end of a topic you can just send the value of the payload:

instar/10D1DC21AABB/alarm/area1/enable  # payload: {"val":"1"}

instar/10D1DC21AABB/alarm/area1/enable/raw  # payload: __1__

But you will still have to use transformations for topics that use on/off instead of 1/0.

These two are doing the same job and they work as expected:

Type switch : alarmArea1Enable	"Alarmbereich 1"		[ stateTopic="instar/10D1DC21AABB/status/alarm/area1/enable", commandTopic="instar/10D1DC21AABB/alarm/area1/enable", on="{\"val\":\"1\"}", off="{\"val\":\"0\"}", qos=1 ]
Type switch : alarmArea1Enable2	"Alarmbereich 1"		[ stateTopic="instar/10D1DC21AABB/status/alarm/area1/enable", commandTopic="instar/10D1DC21AABB/alarm/area1/enable/raw", transformationPattern="JSONPATH:$.val", on="1", off="0", qos=1 ]	

Still don´t believe yours is working… :face_with_raised_eyebrow:

1 Like

You are right - I just checked and I am not using a value transformation here. I will update the screenshots tomorrow :nerd_face:

And that is the problem.
OH REST is only using POST to set a state.
GET is only avaliable with the old Classic-UI, which i don´t want to install only to get GET…

As far as I know GET is working fine with HomeMatic, FHEM, ioBroker.

so i have to use POST:

curl -X POST --header "Content-Type: text/plain" --header "Accept: application/json" -d "test" "http://openhabian:8080/rest/items/sv_Camera"

…is working:

Is this all i have to do?!

what can be added here?

At the moment nobody want´s to jump arround infront of my cam :neutral_face:

Yes, that is true - it is not only GET. You can also use POST with the cameras alarm server. So this should work.

And here are a few example how you can use alarm server queries with Node-RED. I haven’t tried using them in OH directly, though.

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 :slightly_smiling_face: In case of Node-RED you simply upload the public key.
1 Like

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.

here we go…
tested “alarm/triggered”

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”.

Good morning @Dragonfly,

How can you have a value reset itself in OpenHAB? I solved a similar problem in Node-RED by adding a delayed update back to an idle value.

It is working.
Reset the value within openHAB, no need to do the reset within the camera:

rule "Kamera - Eingang/Alarm ausgelöst"
	Item Kamera_EG_alarmTriggered changed
	if (Kamera_EG_alarmTriggered.state != 0){Kamera_EG_alarmTriggered.sendCommand(0)}

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.

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!