You are right - I just checked and I am not using a value transformation here. I will update the screenshots tomorrow 
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 
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
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"
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.
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.