HTTP API for Scene access / error logging

Discussions about Z-Way software and Z-Wave technology in general
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

HTTP API for Scene access / error logging

Post by ridewithstyle »

Hello there,

I am currently including my EntryCom VersoIP Doorbell into ZWay. I can already trigger actions within the doorbell unit from zway via http-device app.

But what really drives me up the wall is, that I cannot trigger scenes in zway.

If I use

Code: Select all

curl -v -u user:pwd http://192.168.0.27:8083/ZAutomation/api/v1/devices/LightScene_166/command/on
from my machine and the scene gets triggered fine. So I know that I am not completely off. The /var/log/z-way-server.log shows

Code: Select all

[2018-10-22 22:45:36.797] [I] [core] ---  LightScene_166 performCommand processing: {"0":"on","1":{}}
But here's the problem: if I trigger this command from the entrycom unit, nothing happens. And since the razberry-log doesn't show errors, I'm quite lost. I don' even know if the request reaches zway.

Can anybody please point me into the right direction? First step is, I need more visibility. If I deliberately change the password to the wrong value, I cannot see any log entry.

Second, I need to fill the proper fields in the entrycom unit:

URI:http://192.168.0.27:8083/ZAutomation/ap ... command/on
Username:myname
Password:mypasswd
Method:GET
Type:application/json can also be text/plain
Text:<blank>

The entrycom documentation tells me that

Parameters
Event – define the event to launch the action.
Condition – define the condition to be met to execute the action. This parameter is optional.
Uri – define the standard HTTP URI including the destination address and, optionally, the path and other parameters. The maximum length is 2048 bytes.
Username – define the username in case authorisation is required by the HTTP server. This parameter is optional. The default value is "intercom".
Password – define the password in case authorisation is required by the HTTP server. This parameter is optional.
Method – define the HTTP request method: GET, POST, PUT, DELETE.
Type – select the type of the HTTP request body content: "application/json" or "text/plain". Applies to valid methods POST and PUT only.
Text – select the request text content. Applies to valid methods POST and PUT only.

If I use curl, I can see that it uses GET, but that doesn't seem to trigger properly from the entrycom unit.

Can anybody spot something, that I have missed? Help is really appreciated!

Best regards,
rws
User avatar
PoltoS
Posts: 7562
Joined: 26 Jan 2011 19:36

Re: HTTP API for Scene access / error logging

Post by PoltoS »

I believe the entrycom is lot sending correct basic with request

You might need to force it to send the auth data

Try tcpdump to debug it
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

Re: HTTP API for Scene access / error logging

Post by ridewithstyle »

Yes, I concur. I set up the entrycom so it feeds my syslog server and set the highest debug level. Then I programmed the http trigger as loop to the entrycom and triggerd some audio file. That works and I can see the request in syslog. But if I Target zway, then I can see that the entrycom wants to trigger but I can see the tcp notification. I presume it's the 8083 port within the URL which breaks the parser, ticket against entrycom is already open.

Will keep this topic updated once solve this.

Regards, rws
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

Re: HTTP API for Scene access / error logging

Post by ridewithstyle »

quick update: the entrycom unit support (2n) claims that they see the call in their tcpdump that I created for them. But they get an 401 error access denied. Is there any way to up the level of z-way logging so I can see what z-way receives as http request?

Best regards,
rws
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

Re: HTTP API for Scene access / error logging

Post by ridewithstyle »

Hi there,

I just took a look at the wireshark dump myself and I cannot see the credentials. Shouldn't I be able to see credentials in the GET?

0000 b8 27 eb cf 28 5b 7c 1e b3 02 89 15 08 00 45 00 ¸'ëÏ([|.³.....E.
0010 00 b8 79 e6 00 00 ff 06 bf c3 c0 a8 00 2a c0 a8 .¸yæ..ÿ.¿ÃÀ¨.*À¨
0020 00 1b fb 54 1f 93 d8 aa bd 8f 3d 11 23 c1 50 18 ..ûT..ت½.=.#ÁP.
0030 80 00 f2 c3 00 00 47 45 54 20 2f 5a 41 75 74 6f ..òÃ..GET /ZAuto
0040 6d 61 74 69 6f 6e 2f 61 70 69 2f 76 31 2f 64 65 mation/api/v1/de
0050 76 69 63 65 73 2f 4c 69 67 68 74 53 63 65 6e 65 vices/LightScene
0060 5f 31 36 35 2f 63 6f 6d 6d 61 6e 64 2f 6f 6e 20 _165/command/on
0070 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 HTTP/1.1..Host:
0080 31 39 32 2e 31 36 38 2e 30 2e 32 37 3a 38 30 38 192.168.0.27:808
0090 33 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 48 3..User-Agent: H
00a0 49 50 20 32 2e 32 34 2e 31 2e 33 33 2e 31 31 0d IP 2.24.1.33.11.
00b0 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
00c0 20 30 0d 0a 0d 0a 0....

Z-Way replies

0000 7c 1e b3 02 89 15 b8 27 eb cf 28 5b 08 00 45 00 |.³...¸'ëÏ([..E.
0010 02 9b c0 09 40 00 40 06 f6 bd c0 a8 00 1b c0 a8 ..À.@.@.ö½À¨..À¨
0020 00 2a 1f 93 fb 54 3d 11 23 c1 d8 aa be 1f 50 18 .*..ûT=.#Áت¾.P.
0030 75 40 fa 16 00 00 48 54 54 50 2f 31 2e 31 20 34 u@ú...HTTP/1.1 4
0040 30 31 20 55 6e 61 75 74 68 6f 72 69 7a 65 64 0d 01 Unauthorized.
0050 0a 53 65 72 76 65 72 3a 20 4d 6f 6e 67 6f 6f 73 .Server: Mongoos
0060 65 2f 36 2e 34 0d 0a 43 6f 6e 74 65 6e 74 2d 54 e/6.4..Content-T
0070 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e ype: application
0080 2f 6a 73 6f 6e 3b 20 63 68 61 72 73 65 74 3d 75 /json; charset=u
0090 74 66 2d 38 0d 0a 58 2d 41 50 49 2d 56 45 52 53 tf-8..X-API-VERS
00a0 49 4f 4e 3a 20 32 2e 30 2e 31 0d 0a 44 61 74 65 ION: 2.0.1..Date
00b0 3a 20 54 68 75 2c 20 30 31 20 4e 6f 76 20 32 30 : Thu, 01 Nov 20
00c0 31 38 20 31 36 3a 32 31 3a 32 34 20 47 4d 54 0d 18 16:21:24 GMT.
00d0 0a 41 63 63 65 73 73 2d 43 6f 6e 74 72 6f 6c 2d .Access-Control-
00e0 45 78 70 6f 73 65 2d 48 65 61 64 65 72 73 3a 20 Expose-Headers:
00f0 41 63 63 65 70 74 2d 52 61 6e 67 65 73 2c 20 43 Accept-Ranges, C
0100 6f 6e 74 65 6e 74 2d 45 6e 63 6f 64 69 6e 67 2c ontent-Encoding,
0110 20 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 2c Content-Length,
0120 20 43 6f 6e 74 65 6e 74 2d 52 61 6e 67 65 2c 20 Content-Range,
0130 43 6f 6e 74 65 6e 74 2d 54 79 70 65 2c 20 45 54 Content-Type, ET
0140 61 67 2c 20 58 2d 41 50 49 2d 56 45 52 53 49 4f ag, X-API-VERSIO
0150 4e 2c 20 44 61 74 65 2c 20 43 61 63 68 65 2d 43 N, Date, Cache-C
0160 6f 6e 74 72 6f 6c 2c 20 49 66 2d 4e 6f 6e 65 2d ontrol, If-None-
0170 4d 61 74 63 68 2c 20 43 6f 6e 74 65 6e 74 2d 4c Match, Content-L
0180 61 6e 67 75 61 67 65 2c 20 41 63 63 65 70 74 2d anguage, Accept-
0190 4c 61 6e 67 75 61 67 65 2c 20 5a 57 41 59 53 65 Language, ZWAYSe
01a0 73 73 69 6f 6e 0d 0a 41 63 63 65 73 73 2d 43 6f ssion..Access-Co
01b0 6e 74 72 6f 6c 2d 41 6c 6c 6f 77 2d 4f 72 69 67 ntrol-Allow-Orig
01c0 69 6e 3a 20 2a 0d 0a 41 63 63 65 73 73 2d 43 6f in: *..Access-Co
01d0 6e 74 72 6f 6c 2d 41 6c 6c 6f 77 2d 4d 65 74 68 ntrol-Allow-Meth
01e0 6f 64 73 3a 20 47 45 54 2c 20 50 4f 53 54 2c 20 ods: GET, POST,
01f0 50 55 54 2c 20 44 45 4c 45 54 45 2c 20 4f 50 54 PUT, DELETE, OPT
0200 49 4f 4e 53 0d 0a 41 63 63 65 73 73 2d 43 6f 6e IONS..Access-Con
0210 74 72 6f 6c 2d 41 6c 6c 6f 77 2d 48 65 61 64 65 trol-Allow-Heade
0220 72 73 3a 20 41 75 74 68 6f 72 69 7a 61 74 69 6f rs: Authorizatio
0230 6e 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 n..Connection: c
0240 6c 6f 73 65 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 lose..Content-Le
0250 6e 67 74 68 3a 20 37 37 0d 0a 0d 0a 7b 22 64 61 ngth: 77....{"da
0260 74 61 22 3a 6e 75 6c 6c 2c 22 63 6f 64 65 22 3a ta":null,"code":
0270 34 30 31 2c 22 6d 65 73 73 61 67 65 22 3a 22 34 401,"message":"4
0280 30 31 20 55 6e 61 75 74 68 6f 72 69 7a 65 64 22 01 Unauthorized"
0290 2c 22 65 72 72 6f 72 22 3a 22 4e 6f 74 20 6c 6f ,"error":"Not lo
02a0 67 67 65 64 20 69 6e 22 7d gged in"}

Still, a nice touch would have been if the failed attempt would show in the z-way-server log. That would have saved me a lot of time. If you add a printf, that would help in the future.

Will keep you updated

rws
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

Re: HTTP API for Scene access / error logging

Post by ridewithstyle »

Update: just for kicks and since they don't seem to have a CURL enabled client, I setup a window powershell script so that 2N can compare how to properly prepare a header for authentication

Code: Select all

$user = "entrycom"
$pass = "password"
$pair = "${user}:${pass}"

$bytes = [System.Text.Encoding]::ASCII.GetBytes($pair)
$base64 = [System.Convert]::ToBase64String($bytes)

$basicAuthValue = "Basic $base64"

$headers = @{ Authorization = $basicAuthValue }

Invoke-WebRequest -uri "http://192.168.0.27:8083/ZAutomation/api/v1/devices/LightScene_165/command/on" -Headers $headers
Then I captured a wireshark pcap and sent them both captures for comparison. Currently they are trying to wrap their head around why they don't send an http authentication header.

Regards,
rws
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

Re: HTTP API for Scene access / error logging

Post by ridewithstyle »

Hello there,

I got feedback from the 2n support. They use digest/nonce for encrypting the password, they do not support unencrypted passwords for security reasons.

The 401 reply that z-way sends does not contain a nonce, am I correct? I took a look at the 401 reply and cannot see a hint.

Can any of the Coders please comment?

Thanks and best regards,
rws
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

Re: HTTP API for Scene access / error logging

Post by ridewithstyle »

Hi there,

I finally got some proper developer feedback from 2N, I'll just paste the reply here

Code: Select all

I have some conclusion for you.

As you can see on image below, left side shows communication between 2N IP intercom and 2N IP intercom, so one is server and second is as client. 

When HTTP command is sent, server side tells client side which authentication methods will be used in header showing those methods, and client side choose the more secured one.

When we take a look on right side of image it shows communication with your server, which however does not reply with header offering authentication methods. In such case IP intercom will choose to use more secured again.

So as conclusion, if your server sends in header it wants to use basic method, IP intercom will use it.

It is possible when web browser receives such reply from your server it will just try basic first so it works for you, however our devices are designed to use more secured way of communication if server does not properly responds.

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent (e.g. a web browser) to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field of the form Authorization: Basic <credentials>", where credentials is the base64 encoding of id and password joined by a colon.

It is specified in RFC 7617 from 2015, which obsoletes RFC 2617 from 1999.

So we are using Basic according to this RFC and we are expecting to received header with authentication methods available. .
So it seems that Z-Way needs to "simply" ask for basic authentication and we're done here (or implement Digest authentication as well).

Can I request this as a feature update? :-)

Thanks and best regards,
rws
Attachments
Proper_auth.png
Proper_auth.png (151.56 KiB) Viewed 8270 times
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

Re: HTTP API for Scene access / error logging

Post by ridewithstyle »

Any of the developers care to comment on this? It's a real bugger that I can't integrate my doorbell into z-way :-/

Regards,
rws
ridewithstyle
Posts: 155
Joined: 02 Jan 2016 01:20

Re: HTTP API for Scene access / error logging

Post by ridewithstyle »

Would someone be willing to add the proper reply to ask for basic authentication? This is currently really a blocking point for me.

Best regards,
rws
Post Reply