Simple HTTP Connector For Flows

I commented on the GitHub issue as well. Would it be possible to use the public:true API. This would at least allow devices to still communicate with Homey (until Athom also kills that).

That’s an existing feature (disable authorisation on settings screen; restart app). I’m thinking on a solution to get whitelisting working again.

3 Likes

Hi Erik,

Is this APP working with the Homey v2? Because when i open de http request it can’t find my homey anymore. I’m not using the whitelist and using the extern url/cloud connection.

Hi All,

I try to change the status of an item in openhab. I tested this successfully in openhab with the following command:

curl -X PUT --header “Content-Type: text/plain” --header “Accept: application/json” -d “ON” “http://192.168.178.55:8080/rest/items/check_in/state

Is there a way to build this into an homey action card?
I believe, I got stuck because openhab requires a plain text type.

thanks in advance

Perhaps a “POST form” card with the following string as URL (and as value just “ON”):

{"method":"put","protocol":"http:","hostname":"192.168.178.55","port":8080,"path":"/rest/items/check_in/state","headers":{"content-type":"text/plain","accept":"application/json"}}

Reading this: https://community.openhab.org/t/http-binding-using-put-methods/38793 I think openhab also accepts json, so something like {“state”: “ON”} on endpoint http://192.168.178.55:8080/rest/items/check_in

Thanks Robert and Erik…I tried both solutions…both didn’t work.

Robert: I tried your string as URL value on a POST form card and I got a reply “Cannot read property ‘indexOf’ of null”. Altered a few things, but no results
{“method” : ”put” , ”protocol” : ”http:” , ”hostname” : ”192.168.178.55” , ”port”:8080, ”path” : ”/rest/items/check_in/state” , ”headers” : {“content-type” : ”text/plain” , ”accept” : ”application/json”}} and a value of {“ON”}

Erik: I tried the PUT json card and all responses were 400

Any other suggestions?

Sorry for the bolt text… worked partly on desktop and mobile… text entered on the desktop and send by molbile seems to become bolt

I don’t think {“ON”} is a valid value. Either try ON, "ON" or {"state":"ON"} (and literally those values, not with fancy quote characters).

Unfortunatly all those values “ON”, ON and {“state”:”ON”} didn’t work.

There is also a working post request to change an item in openhab. Is this request doable?

curl -X POST --header “Content-Type: text/plain” --header “Accept: application/json” -d “OFF” “http://192.168.178.55:8080/rest/items/check_in?api_key=Websocket&api_key=Websocket

Thanks in advance

I have an issue with triggers. This is my setup:

Trigger “tBatteryJSON2” never gets triggered:

Any idea how to get “tBatteryJSON2” triggered?

Hi @gagga. What is the response you get from “http://sonne.publicinsight.de/api/v1/status”? That uri does not work when I request it.

sonne.publicinsight.de resolves to an internal IP address in my network (192.168.1.10). So it won’t work for you.
From the internal network I get:
{“BatteryCharging”:false,“BatteryDischarging”:true,“Consumption_W”:695,“Fac”:50,“FlowConsumptionBattery”:true,“FlowConsumptionGrid”:true,“FlowConsumptionProduction”:false,“FlowGridBattery”:false,“FlowProductionBattery”:false,“FlowProductionGrid”:false,“GridFeedIn_W”:-35,“IsSystemInstalled”:1,“Pac_total_W”:620,“Production_W”:0,“RSOC”:12,“Timestamp”:“2019-05-06 22:11:57”,“USOC”:7,“Uac”:224,“Ubat”:51}

Unfortunantly that’s an invalid JSON structure. It uses the wrong type of quotes (check it with https://jsonformatter.curiousconcept.com/)

There seems to be an issue with this forum software. If I copy the original output it is verified correctly:

Ok, thats kind of a relieve :).
Are you sure the second flow is enabled?
Can you run flow 1 manual and trigger the ‘send diagnostic report to developer’? I then will have insight in executed requests, returned responses and the jsonPath processing.

Yes. All 3 flows are enabled.
Diagnostic report id: 3ba3d16f-9a93-4a32-b728-4e1b7e0bc7dc

FYI: today’s Homey update to versions 2.1.2 did not change the trigger behaviour.

1 Like

I found the bug and fixed it in version 2.0.10, which is now awaiting approval in the app store.

1 Like