MQTT Full HD Camera for OpenHAB

[mpol (Mike Polinowski)]

This is how you add an INSTAR Full HD MQTT camera to the OpenHAB 2.5 PaperUI.

MQTT Broker

You start by configuring the MQTT broker inside the cameras webUI under Network. Here you can set:

• MQTT Server Address: Leave at 127.0.0.1 to use the internal broker
• MQTT Server Port: Default 1883, adjust if needed
• Username /Password: Set your own login

Now go to the PaperUI Add-Ons Menu and click on the Bindings tab. To be able to connect to the INSTAR MQTT Server we need to install the MQTT Binding - make sure that you choose the Version 2.

Then open your Inbox, click the plus icon, then Add Manually and choose an MQTT Broker.

The broker address is the IP of our INSTAR Full HD camera. Add the port and login you choose in the earlier step. After confirming your settings, you should see that the MQTT broker is listed as ONLINE in the Things menu.

MQTT Interface

The complete MQTT API is documented here. It basically mirrors the cameras webUI. E.g. to switch the motion detection areas you have to navigate the webUI to Alarm / Areas. The MQTT topic to switch Area 1 on or off is alarm/area1/enable. The payload of this topic is:

• {“val”:”0”} /switch off
• {“val”:”1”} /switch on

Since we can have more than one camera on our network, we also need to add an ID for the camera we want to contact. This ID always starts with instar followed by local (to contact the camera that runs the MQTT broker), all (to send the message to all INSTAR cameras on the MQTT network) or the LAN MAC address of a camera to target it specifically:

• instar/local/alarm/area1/enable
• instar/all/alarm/area1/enable
• instar/000389888811/alarm/area1/enable

And one more thing – every of those, so called COMMAND Topics, also has a corresponding STATE Topic:

• instar/local/alarm/area1/enable
• instar/local/status/alarm/area1/enable

We use the first one to update / switch something on our camera and – once this happened successfully – receive a state update to set the state of our Paper UI switch.

MQTT Things

Just like you added the MQTT broker you can now add a Generic MQTT Thing name it Alarm Areas and bridge it with the broker you just added (See tutorial on Github) for more screenshots).

Confirm your edits and click on the MQTT Thing you just created to add a channel with the following configuration:

• Channel type: On/Off Switch
• Channel ID: AlarmArea1
• Channel type: Alarm Area 1
• MQTT State Topic: instar/local/status/alarm/area1/enable
• MQTT Command Topic: instar/local/alarm/area1/enable
• Custom ON Value: {"val": "1"}
• Custom OFF Value: {"val": "0"}
• QoS: At least Once

Now all we have to do is linking everything to an UI element of type switch. Switch to the Control tab – it should now hold a switch that can activate and deactivate the alarm area 1 on your camera.

Automations

The MQTT API documentation covers the complete set of functions the camera offers. All ready to go to be connected to a UI element or an automation script inside OpenHAB.

[mpol (Mike Polinowski)]

On all Full HD camera models with the current firmware you can now set the alarm server interval via CGI command. The default value is 60s:

/param.cgi?cmd=setmdalarm&-aname=server2&-switch=on&-interval=60

A reduction down to one second is possible - but we recommend to leave it at least 10-15s (if not needed otherwise on the smarthome side). For example, to set the interval between alarm triggers for a camera with the IP 192.168.178.102 and the HTTP port 80 to 15s

http:// 192.168.178.102:80/param.cgi?cmd=setmdalarm&-aname=server2&-switch=on&-interval=15

The alarm server is used to inform OpenHAB when motion is detected by the camera.

[Dragonfly (Thomas Baumgartner)]

Are you sure, that it is refreshing its state if you switch the alarm area on/off in the Cameras-UI ?

I made this with a .things-file:

Bridge mqtt:broker:localhost "MQTT Bridge - localhost" [ host="127.0.0.1", port=1883, secure=false, username="openhabian", password="pwd", qos=1 ]
{
Thing topic 10D1DC21AABB "IN-9020 @ MQTT Bridge - localhost" {
Channels:
        Type switch : alarmArea1 "Alarmbereich 1" [ stateTopic="instar/10D1DC21AABB/status/alarm/area1/enable", commandTopic="instar/10D1DC21AABB/alarm/area1/enable", on="{\"val\":\"1\"}", off="{\"val\":\"0\"}", qos=1 ]

}

}

Switch	test		"Alarmbereich 1"	{channel="mqtt:topic:localhost:10D1DC21AABB:alarmArea1"} 

It is working with this code;

If I add

transformationPattern="JSONPATH:$.val"

to my channel the Item does not refresh the state if it is switched over the cameras UI.

Transformation should be already be done here:

 on="{\"val\":\"1\"}"

This combination is working for incomig, not for outgoing events:

on="1", off="0", transformationPattern="JSONPATH:$.val", transformationPatternOut="JSONPATH:$.val"

Can you please check this?!

Thank you, Thomas

[Dragonfly (Thomas Baumgartner)]

@mpol

The alarm server is used to inform OpenHAB when motion is detected by the camera.

How?!
Can you post the MQTT topics you use for it?

[Dragonfly (Thomas Baumgartner)]

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

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:

instar/10D1DC21AABB/status/features/nightvision/currentbrightness

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

Thank you very much…

[mpol (Mike Polinowski)]

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:

IpCamera: New IP Camera Binding

This binding is now merged into openHAB 2.5.9 and newer. See below for more details on what each brand of camera has working as often choosing the right camera will save you from needing to purchase an extra video server (both the cost to purchase the server, plus the ongoing electricity costs) to process the video feeds. Features for Generic cameras with only RTSP (no snapshot url): Snapshots (jpg) can be created from RTSP with low CPU overhead but requires non stop network traffic to keep …

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

[mpol (Mike Polinowski)]

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.

[Dragonfly (Thomas Baumgartner)]

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…

[mpol (Mike Polinowski)]

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

[Dragonfly (Thomas Baumgartner)]

@mpol

The alarm server will send an HTTP GET request to a webhook that has to be provided by OpenHAB.

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…
→ https://community.openhab.org/t/solved-use-url-to-manipulate-items-in-oh2/8732/13

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

[mpol (Mike Polinowski)]

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.

[mpol (Mike Polinowski)]

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.

[mpol (Mike Polinowski)]

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.

[Dragonfly (Thomas Baumgartner)]

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

[mpol (Mike Polinowski)]

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.

[Dragonfly (Thomas Baumgartner)]

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…

[mpol (Mike Polinowski)]

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.

[Dragonfly (Thomas Baumgartner)]

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…

[mpol (Mike Polinowski)]

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

[rossko57]

@Dragonfly

Which means, openHAB is only detecting a triggered alarm on change, not on update.

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.