HC2 responding slow to API commands

[Lights-on 0]

Hi,

 

I tend to control my lights via HC2 by using the REST API.

In my setup i am using the HC2 as a gateway in between my Crestron CP3 processor (which is the main controller) and all the lighting fixtures connected and controlled by the HC2.

The Crestron controller is sending http command strings over a TCP connection to the HC2 controller.

 

For example when using the TurnOn and TurnOff command via the API Doc webinterface commands are carried out immediately with no delays.

Please login or register to see this link.

 

However when sending the same command to the HC2 by using the Crestron controller it takes at least 30 seconds up to 1 minute before any reaction follows and the command is carried out.

 

Strange thing : There is a difference in behavior. 

 

When sending command string for Resfreshstates : GET /api/refreshStates?last=1 HTTP/1.1\nHost: %s\nAccept: application/json\nAuthorization: Basic bWFyaW9AbGlnaHRzLW9uLm5sOk1hcmlvX0thc3RlbGVpbl8xOTgy\n\n

This command is carried out immediately by the HC2 when sent from the Crestron controller. No delays at all, immediate response.

 

But when sending the TurnOn or TurnOff command over the same connection, using the same principle : POST /api/devices/45/action/turnOn HTTP/1.1\nHost: %s\nAccept: application/json\nAuthorization: Basic bWFyaW9AbGlnaHRzLW9uLm5sOk1hcmlvX0thc3RlbGVpbl8xOTgy\n\n

 

it takes 30 seconds up to 1 minute before the actual command is carried out and any response from the HC2 will follow.

 

Any suggestions to solve this?

[jgab 2,642]

I believe there is an issue with the POST arguments. Probably need an empty {args={}} payload.

For turnOn and turnOff you could try to use the GET/callAction  version instead

 

Ex.

Please login or register to see this code.

 

Edited June 6, 2022 by jgab

[petergebruers 1,268]

On 6/6/2022 at 7:57 PM, Lights-on said:

Authorization: Basic bWFya

 

That decodes as:

 

ma****on.nl:Ma***82

 

If that is not a test password then............ now is a good time to change your password

Edited June 8, 2022 by petergebruers

[jgab 2,642]

18 hours ago, petergebruers said:

That decodes as:

.....

If that is not a test password then............ now is a good time to change your password

@petergebruers most forum members don't have the massive computing power you have, to brute force that credential  

[petergebruers 1,268]

27 minutes ago, jgab said:

massive computing power you have, to brute force that credential

 

You are joking, right? I am asking, because I feel somewhat insulted by the suggestion that "I brute forced" anything.

 

The password is not encrypted in any way. Just Google "base64 online" decoder. Paste the auth string.

 

The username and password will appear in plain text.

 

As I said: the OP accidentally disclosed his credentials, we cannot fix this after the fact.

[Comfortica 17]

30 minutes ago, petergebruers said:

 

You are joking, right? I am asking, because I feel somewhat insulted by the suggestion that "I brute forced" anything.

 

The password is not encrypted in any way. Just Google "base64 online" decoder. Paste the auth string.

 

The username and password will appear in plain text.

 

As I said: the OP accidentally disclosed his credentials, we cannot fix this after the fact.

He is joking for sure

 

 

[SmartHomeEddy 1,005]

base64 online is kinda brute force ?

 

 

 

 

Edited June 7, 2022 by SmartHomeEddy

[petergebruers 1,268]

1 hour ago, Comfortica said:

He is joking for sure

 

Hehehe @jgab and I have known eachother for years. I am sure it was meant as a compliment.

 

 

49 minutes ago, SmartHomeEddy said:

base64 online is kinda brut force ?

LOL - the internet! The power! Google! Imagine a world without it.

 

May the force be with us!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[Lights-on 0]

Hi All, 

 

That was kind of stupid of me to post the pass... 

Thanks for letting me know. All passwords has been changed right away.

 

Back to the topic:

Wat is the isssue with the post commands then? 

Ik i should add an empty arg payload within the command string, how should that be added to make use of it?

 

For the TurnOn and TurnOff command the workaround of using the GET command might work, but next phase is when i would like to control intensity values etc over API, that's also POST command.

What is the actual difference between using de API-docs page and sending the same command string from another device, since the same commands are working fine when sent from the API-docs page directly.

[petergebruers 1,268]

On 6/6/2022 at 7:57 PM, Lights-on said:

GET /api/refreshStates?last=1 HTTP/1.1\nHost: %s\nAccept: application/json\nAuthorization: Basic bWFyaW\n\n

This command is carried out immediately by the HC2 when sent from the Crestron controller. No delays at all, immediate response.

"refreshStates" will block for 30 seconds if there is nothing happening on HC2. On a very active HC you may not notice, let's say randomly 1 of your 100 devices reports a temperature, or a voltage, or motion, .... that will cause a response to be returned to your blocked http channel.

 

So if refreshStates is part of your loop on Crestron, that might explain some of the randomness and delays.

 

16 minutes ago, Lights-on said:

What is the actual difference between using de API-docs page and sending the same command string from another device, since the same commands are working fine when sent from the API-docs page directly.

Actually, not much indeed.... If you use the "docs" then there is no "physical ethernet" but still the API goes through TCP/IP stack and same process to handle your http requests.

 

Technically, there is a proxy server between LAN and the process handling the "api/device/... etc" url but AFAIK I does not cause trouble.

 

I wonder if you have a second problem. If you try to call a scene, but that scene is already running, and you have "%% killOtherInstances" in the header of that scene... Then the "kill" might take 10 seconds. I am not sure if this buk aka "feature" is solved, I am not using a HC2 in production (production is on a HC3)

 

 

 

 

 

Edited June 8, 2022 by petergebruers

[Lights-on 0]

26 minutes ago, petergebruers said:

 

Quote

Actually, not much indeed.... If you use the "docs" then there is no "physical ethernet" but still the API goes through TCP/IP stack and same process to handle your http requests.

 

Technically, there is a proxy server between LAN and the process handling the "api/device/... etc" url but AFAIK I does not cause trouble.

I do use the refresh command occasionally, but also when i don't fire the refresh command the TurnOn and TurnOff command is being delayed when sent through Crestron. Even when the refresh command hasn't been used at all.

 

Then if there is no actual difference between the Docs page and sending the same commands over Crestron, why is there still a difference in behavior? As far as my knowledge goes it looks like that HC2 is handling commands differently in both situations, or might LAN infrastructure in between causing issues? But then still don't uderstand why the same principle by using the doc's page is actually working fine and via Crestron it doenst as both are using the same infrastructure

[petergebruers 1,268]

19 minutes ago, Lights-on said:

but also when i don't fire the refresh command the TurnOn and TurnOff command is being delayed when sent through Crestron. Even when the refresh command hasn't been used at all.

Okay. Good info.

 

19 minutes ago, Lights-on said:

Then if there is no actual difference between the Docs page and sending the same commands over Crestron, why is there still a difference in behavior?

I hate to say it, but I have been using "Home Assistant" with both HC2 and HC3 "connected through the API" (so to speak) for many years and I can assure you, there are no delays like you have reported im post #1. HASS also uses refreshStates and the documented API calls, nothing unexpected there. From this I conclude that there is no fundamental flaw either in refreshStates nor does delay get above a second when HASS calls the API to eg turn on a light.

 

Now simply pointing to "it is your Crestron" or "you are doing something wrong" isn't helpful either but at least we can eliminate the HC2 from the list of possible causes. Barring those issues with refresStates and killing Scenes causing 10 second hang-ups.

 

If you can read "Python" code then the HASS to HC integration might be something for you to look at.

 

19 minutes ago, Lights-on said:

or might LAN infrastructure in between causing issues?

I wouldn't expect random delays like that but if you know how to handle "Wireshark" and have a managed switch, you might be able to sniff the traffic between the Crestron controller and the HC. I admit, I am thinking out loud here, not sure what I'd expect to see there.

 

I don't know what a "Crestron" is but isn't everything a Linux under the hood these days?

 

19 minutes ago, Lights-on said:

But then still don't uderstand why the same principle by using the doc's page is actually working fine and via Crestron it doenst as both are using the same infrastructure

Can you please do another test?

 

Assuming you have a PC with recent windows or MAC or Linux, can you try "curl" with the same commands? If it is fast, which I expect, then it is a more likely to be a Crestron problem. If it is slow, then it is your LAN or something about those commands. Try some more commands, like starting a scene or getting/setting a global variable maybe.

Edited June 8, 2022 by petergebruers

[Lights-on 0]

Quote

Assuming you have a PC with recent windows or MAC or Linux, can you try "curl" with the same commands? If it is fast, which I expect, then it is a more likely to be a Crestron problem. If it is slow, then it is your LAN or something about those commands. Try some more commands, like starting a scene or getting/setting a global variable maybe.

 

@petergebruers please forgive me for asking, but what do you actually mean with "curl" with the same commands? 

[Lights-on 0]

Quote

On 6/6/2022 at 8:31 PM, jgab said:

I believe there is an issue with the POST arguments. Probably need an empty {args={}} payload.

For turnOn and turnOff you could try to use the GET/callAction  version instead

 

Ex.

Please login or register to see this code.

 

@jgabThat doesnt seem to work. that generates : 00:01:30.875    HTTP/1.1 400 Bad Request\x0D\x0AServer: nginx/1.8.0\x0D\x0ADate: Wed, 08 Jun 2022 19:18:06 GMT\x0D\x0ATransfer-Encoding: chunked\x0D\x0AConnection: keep-alive\x0D\x0A\x0D\x0A0\x0D\x0A\x0D\x0A    HC2_Data_Rx$

Are you sure the command string should look like :

GET /api/callAction?deviceID=45&Schemerlamp TV=turnOn HTTP/1.1\x0D\x0AHost: %s\x0D\x0AAccept: application/json\x0D\x0AAuthorization: XXXXXX

 

This time i added XXXX for the authorization part
 

[jgab 2,642]

8 hours ago, Lights-on said:

Are you sure the command string should look like :

GET /api/callAction?deviceID=45&Schemerlamp TV=turnOn HTTP/1.1\x0D\x0AHost: %s\x0D\x0AAccept: application/json\x0D\x0AAuthorization: XXXXXX

 

This time i added XXXX for the authorization part
 

No, name is 'name' and not the name of the device

deviceID=45

name=turnOn

 

GET /api/callAction?deviceID=45&name=turnOn HTTP/1.1\x0D\x0AHost: %s\x0D\x0AAccept: application/json\x0D\x0AAuthorization: XXXXXX

[petergebruers 1,268]

14 hours ago, Lights-on said:

but what do you actually mean with "curl" with the same commands?

Don't worry about it if you have never used it, it is another tool to learn for you and I am not sure it will give us a lot of new info.

 

14 hours ago, Lights-on said:

This time i added XXXX for the authorization part

Much better

 

5 hours ago, jgab said:

GET /api/callAction?deviceID=45&name=turnOn HTTP/1.1\x0D\x0AHost: %s\x0D\x0AAccept: application/json\x0D\x0AAuthorization: XXXXXX

 

I am not sure what a "crestron controller" expects as a string, going by that example it looks like you are doing pretty "low level stuff" so might actually be more like a TCP string than a http string.

 

What I am saying is this... If it is really low level, then the http protocol expects to terminate by sending a blank line This means your command should end with "\x0D\x0A\x0D\x0A" which is a a "line end" (CR LF) pair followed by another line end. So the complete command:

 

Please login or register to see this code.

 

Your crestron might add it, it might not be needed, but it is worth trying

 

Please login or register to see this link.

 

I am not sure if that would explain delays, I cannot test it because my HC2 is not connected right now.

 

Also, I did notice @Lights-on had "\n\n" at the end of the string in the first post, so that is very close to what the spec says and probably it is equivalent. IIRC it is one of those things that never was fully followed by any party so depends on implementation.

 

Please login or register to see this code.

 

To follow the spec, all \n should become \r\n like this:

 

Please login or register to see this code.

 

this might all be a "red herring" but on the other hand "the devil is in the detail(s)"

[Lights-on 0]

On 6/6/2022 at 8:31 PM, jgab said:

I believe there is an issue with the POST arguments. Probably need an empty {args={}} payload.

For turnOn and turnOff you could try to use the GET/callAction  version instead

 

Ex.

Please login or register to see this code.

 

This method seems to work, with no delays!

 

However i could not find any documentation for this method in the docs? Is there any location or doc where i can find information about this method and other methods / syntaxes that i can use?

Also now comes the next part ; besides turning lights on and off i would like to change intensities on the fly. Any suggestions concerning this issue and based on the device properties which command / method i should use.

Please find device properties below:

 

{ "id": 45, "name": "Schemerlamp TV", "roomID": 219, "type": "com.fibaro.philipsHueLight", "baseType": "com.fibaro.multimedia", "enabled": true, "visible": true, "isPlugin": true, "parentId": 43, "remoteGatewayId": 0, "interfaces": [ "externalView" ], "view": [ { "name": "brightness", "type": "slider", "attributes": { "min": 0, "max": 255, "step": 1 } }, { "name": "onOff", "type": "switch", "attributes": { "captionOn": "i18n_onOff_ON", "captionOff": "i18n_onOff_OFF", "imageOn": "", "imageOff": "", "class": "" } } ], "properties": { "alert": "0", "bri": "223", "categories": "[\"multimedia\"]", "ct": "443", "dead": "false", "deadReason": "", "deviceControlType": "0", "deviceIcon": "28", "effect": "0", "emailNotificationID": "0", "emailNotificationType": "0", "hue": "0", "lightId": "3", "log": "", "logTemp": "", "manufacturer": "", "model": "", "mute": "false", "on": "false", "power": "false", "pushNotificationID": "0", "pushNotificationType": "0", "reachable": "false", "remoteGatewayId": "0", "sat": "0", "saveLogs": "true", "smsNotificationID": "0", "smsNotificationType": "0", "state": "", "ui.brightness.value": 223, "ui.hue.value": 0, "ui.labelBrightness.caption": "Brightness", "ui.labelHue.caption": "Hue", "ui.labelSaturation.caption": "Saturation", "ui.onOff.captionOff": "Off", "ui.onOff.captionOn": "On", "ui.onOff.value": false, "ui.saturation.value": 0, "ui.testImg.source": "hue.jpg", "userDescription": "", "volume": "0", "x": "", "y": "" }, "actions": { "setMute": 1, "setVolume": 1, "turnOff": 0, "turnOn": 0 }, "created": 1654583132, "modified": 1654583132, "sortOrder": 22 }