Selfmade Actor / io Module: Best way to send commands to it?

Hi there,

I’ve build myself a little io module with the help of a raspberry pi.

It controls the inputs and outputs via i2c bus. Apache HTTP Server is running on the raspberry pi and provides a PHP file, which OPENHAB requests to change a output.
This works, but sometimes the HTTP Request fails and OPENHAB thinks it has successfully turned on the Output, even thought it is NOT turned on.
I’d like to send something like an ACK for that. Of course I can’t use HTTP for that purpose. I thought about UDP and building a ACK by myself. I’m open for any other protocoll as well, but it needs to be implemented into a python script.

Can anyone please give me some advice? Thanks!

Why not? Use a Design Pattern: Proxy Item Switch to trigger a rule. Use the sendHttpGetRequest Action to send the command and update your PHP script on the RPi to return success or failure in the body of the return.

rule "RPi Actuator"
    Item ActuatorProxy received command
    val url = if(receivedCommand == ON) onURL else offURL
    val result = sendHttpGetRequest(url)
    if(result != "success") ActuatorProxy.postUpdate(if(receivedCommand == ON) OFF else ON)

I just typed the above in, there are likely typos.

Personally, I would probably use MQTT to send the command and an ack.

Thank you so much. Didn’t know that openhab can save the text from a request!
I will also take a look at MQTT. Thank you!

@rlkoshak I’m using MQTT now. Works so far, but the problem is still there: Openhab does not get any feedback, wheather the output has been sccessfully turned on or not.
Switch MQTT_Test "Testing..." { mqtt="<[habbroker:module/outputs/1-back:state:default], >[habbroker:module/outputs/1:command:*:default]" } }

If I turn this item on, openhab thinks it is on, even thought it is not on (For example, because the IO module lost ethernet connection). Can you give me some advice? I’d like to accomplish this without any rules.

Right, you have to publish the ACK back to OH and update the Item accordingly. Until it gets the ACK back OH will assume that the command was successful.It has nothing else to go on and many technologies provide no ack so there is no way it can wait for an ack in all cases.

You can use a set of semi-complicated rules and a proxy Item. You would send the command to the proxy Item which triggers a Rule that immediately sets the proxy back to the old state and then takes a timestamp and sends the command to an Item that only sends messages to the device. The device sends the ack to a different Item which triggers another rule that updates the Proxy Item.

Or you can use a timer that gets set in the rule triggered by sending a command to the Proxy Item. When the timer goes off it sets the Proxy Item to NULL (indicating that you don’t know what state the device is in). In the rule that triggers on the ACK cancel the timer and update the Proxy Item.