A40 No response

[mickelluiten]

Hi When using the A40 card in a flow i do not get a response from device. I am using Homey Logger. When trigger the flow , the entry is shown in log but nothing happens and no response in log, wondering if the request is send out to device (can't do i wireshark toward device a the moment)

URL : {"method":"put","protocol":"http:","hostname":"192.168.2.15","path":"/api/slot/0/io/relay/4/relayStatus","headers":{"Accept":"vdn.dac.v1","Content-Type":"application/json"}}

JSON : { "slot": 0, "io": { "relay": { "4": { "relayStatus": 0 } } } }

When i using postman i get the 200 OK respone from device (192.168.2.15) and relay will be triggered.

[irritanterik]

Are you sure the request you did with postman is not redirected? The app does not handle http redirections well.

[mickelluiten]

Pretty sure, because postman runs on my laptop i did a wireshark trace.

THis is the trace output

[mickelluiten]

HI, i had some time to do a wireshark trace between homey and device.

The put request is sending out, but i get a 405 Method not allowed return. But this is not in the homey logger!

When i check the trace i see that the header ACCEPT is not sending correct. See my first post what i sending, and my previous post the trace from postman.

note, the GET request is working (card A22) is working with this headers. {"method":"get","protocol":"http:","hostname":"192.168.2.15","path":"/api/slot/0/io/di/0/diStatus","headers":{"Accept":"vdn.dac.v1","Content-Type":"application/json"}}

[irritanterik]

The http.min lib used checks for a header value for 'accept' and goes for 'application/json' if 'accept' not exists. This check is case sensitive. Does your PUT command works when you make the 'Accept' lowercase? You can loos the 'content-type' header by the way, this will default to 'application/json' if not set.

[mickelluiten]

Hi Erik, Not home at the moment, so i can't check it with wireshark. I tryed the accept lowercase with and without content-type but a far as i can see , nothing happens(no relay will be triggerd) and because Homey Logger doesn;'t show any respone i don;t know what i getting back.

What do you mean by : The http.min lib used checks for a header value for 'accept' and goes for 'application/json' if 'accept' not exists?
does this mean that the header vdn.dac.v1 is not registerd or programmed in the http.min lib?

[irritanterik]

If you don't provide a 'accept' value in the custom header, the library used by my app will use 'application/json'. But if you provide a custom header with lowercase 'accept' value this should not be overrided. Can u post the complete entry from the homey logger? With that I can run a local test to check the exact request and behaviour of the homey app.

[irritanterik]

Do you see an error on the flow card when testing the flow?

[mickelluiten]

Yes i getting a error :
unexpected token < in JSON on postition 0

to be sure copyed from card URL : {"method":"put","protocol":"http:","hostname":"192.168.2.15","path":"/api/slot/0/io/relay/3/relayStatus","headers":{"accept":"vdn.dac.v1","Content-Type":"application/json"}}

JSON : { "slot": 0, "io": { "relay": { "3": { "relayStatus": 0 } } }}

[mickelluiten]

Sorry missed you previous post , the home logger output is :

{"datetime":"2018-06-05T19:09:46.914Z","message":"A40 action.http_put_json","data":{"args":{"url":"{\"method\":\"put\",\"protocol\":\"http:\",\"hostname\":\"192.168.2.15\",\"path\":\"/api/slot/0/io/relay/3/relayStatus\",\"headers\":{\"accept\":\"vdn.dac.v1\",\"Content-Type\":\"application/json\"}}","data":"{ \"slot\": 0, \"io\": { \"relay\": { \"3\": { \"relayStatus\": 0 } } }}"},"method":"put","urlOptions":{"method":"put","protocol":"http:","hostname":"192.168.2.15","path":"/api/slot/0/io/relay/3/relayStatus","headers":{"accept":"vdn.dac.v1","Content-Type":"application/json"},"json":{"slot":0,"io":{"relay":{"3":{"relayStatus":0}}}},"timeout":30000}}}

[irritanterik]

Ok, could be fixed now with 3f45cbc8ccda05593ac0fb7f51c8c40dd7d0f870 Can you run this version local and test it with your relay?

[mickelluiten]

HI erik, thanks but what do you mean by test it local? Is the new version available for download thru normal update process in the homey app sotre? or ?? Can you explain it how to do this i'am a noob

[irritanterik]

https://forum.athom.com/discussion/1448/how-to-cli-install-method

Op do 7 jun. 2018 09:09 schreef mickelluiten notifications@github.com:

HI erik, thanks but what do you mean by test it local? Is the new version available for download thru normal update process in the homey app sotre? or ?? Can you explain it how to do this i'am a noob

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/irritanterik/homey-http-request-actions/issues/15#issuecomment-395316701, or mute the thread https://github.com/notifications/unsubscribe-auth/AOhu1MO1f6WPl5Uscd9MNc27w9QSD40Fks5t6NHBgaJpZM4UYsAS .

[mickelluiten]

I have test it , look oke now,

The accept header is now correct, but i still getting a 405 method not allowd back. The relaydevices are Moxa e1214 modules, because in the beginnng i have some problem with postman and the put command i opened a support ticket biy moxa.

Yesterday i receivers a answer, that the homey(or other device) also need to send a header Content-Lenght with value 131 towards the moxa's. i tested this with postman and this works.

I tryed this with homey but as you can see in the trace this is not overwrite by custom value. i'am sending : {"method":"put","protocol":"http:","hostname":"192.168.2.15","path":"/api/slot/0/io/relay/3/relayStatus","headers":{"accept":"vdn.dac.v1","Content-Length":"131"}}

With JSON : {"slot":0,"io":{"relay":{"3":{"relayStatus":0}}}}

also tryed it with lowercase "content-length" but same problem.

Also with postman i needs to Content-Length (uppercase) because when lowercase the moxa send also a 405.

Is this also something you can fix?

[irritanterik]

How is the value of 131 calculated? The homey app is using the exact code equivalent of http://www.modelec.nl/file.php/2781/moxa_tech_note---using_remote_io_with_restful_api.pdf (page 5) for calculating the content-length on PUT requests. (based on Buffer.byteLength(JSON.stringify(data)).

If you add "Content-Length":131 as a header (be aware this is an integer, no string!) this will survive the parsing of the app. I just committed a version where overriding the default "content-length" (lowercase) header is also possible. It is not possible to not send this lowercase header. Will this work for you?

[mickelluiten]

HI, your solution works, the content-length can now be override, but still getting the 405, but i found out what the problem is. The Moxa device only accept uppercase Content-Length. Strange thing is that the accept header and content-type header can both be lower and uppercase toward moxa devices, So the content-lenght that is calculated is correct. I will discuss this with moxa

[mickelluiten]

HI Eric, I have discussed the content-lenght header with Moxa and it is a fault in the firmware. The are going to solve this but the told me that this is going to happen somewhere in the first 3 months of 2019.

But can you explain me why your app only can send lowecase headers? This is not according to the RFC , see https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 Section 4.2 : Field names are case-insensitive

Is it possible to update the app?
Something like setting a flag if the headers are send in uppercase or lowecase? or if you override ican decide if you want lowecase or uppercase(just how you type it)

Let me know, you will make me happy if ths can be done.

[irritanterik]

Hi Mickel. Is this still a problem for you? My app uses the http.min library for buidling the http requests. The default headers are determined by this library.

[mickelluiten]

Hi erik, awaiting firmware from moxa, but i the mean time a altered the code in the http.min file so the Content-Length. will be send with uppercase. This works so no problem anymore at the moment. Thanks for your help and great app.