Local API - Fan does not respond/API call timeouts

I just got my Bond Home with the v2 firmware, I have been working on code to integrate it into my HA system MisterHouse.

When I send commands to one of my fans such as “speed 6” while the fan is off, generally the fan will not come on, in addition at that point I am not able to control that fan from the Android app any more. In order to get the fan to respond to the app again, I have to push any button the regular fan remote. It seems that I can change the speed of the fan with the API commands once its already running which is odd.

Note: This behavior does not seem to be consistent, I was able to get the fan to start a few times by sending a speed command with the API directly. If I don’t send any commands with the API, I am able to consistently control the fan via the app with no issue.

I wrote a quick mock up Perl script that iterates through the devices, gets the names/commands/etc, then iterates through the commands to get the names/etc and dumps them into a hash for use by MisterHouse, from that point on MisterHouse can use the in memory hash instead of constantly pulling the info from the Bond. The problem is that HTTP calls to the Bond randomly timeout during the process of iterating through the devices/commands, I added a retry logic but waiting for a timeout and retrying takes a long time and would delay the application start up.

Version:
“target”:“zermatt”,“fw_ver”:“v2.5.2”,“fw_date”:“Thu Mar 7 19:54:03 UTC 2019”,“manufacturer”:“Olibra”,“model”:“BD-1000”,“branding_profile”:“O_BD-1000”

Fan info:
REMOTE FCCID: CHQ9053T - Frequency 303.798 MHz

$VAR1 = {
‘location’ => ‘Living Room’,
‘name’ => ‘LivingroomFan’,
‘commands’ => {
’ => ‘10c97285’
},
'
’ => ‘bf67a838’,
‘type’ => ‘CF’
};
$VAR1 = {
‘argument’ => ‘’,
‘signal’ => {
’ => ‘0114fe81’
},
'
’ => ‘9fdcd492’,
‘icon’ => ‘button_io’,
‘name’ => ‘Power’,
‘action’ => ‘TurnOff’,
‘tx’ => {
’ => ‘154a2d6a’
}
};
$VAR1 = {
‘tx’ => {
'
’ => ‘5ab1c0b3’
},
‘action’ => ‘SetSpeed’,
‘name’ => ‘Speed 3’,
‘icon’ => ‘button_speed_3’,
’ => ‘3acec72d’,
‘argument’ => ‘’,
‘signal’ => {
'
’ => ‘b03aba03’
}
};
$VAR1 = {
‘name’ => ‘Speed 2’,
‘action’ => ‘SetSpeed’,
‘tx’ => {
’ => ‘38161e2a’
},
‘argument’ => ‘’,
‘signal’ => {
'
’ => ‘10caa39e’
},
‘icon’ => ‘button_speed_2’,
’ => ‘1104d773’
};
$VAR1 = {
‘icon’ => ‘button_speed_6’,
'
’ => ‘346b973d’,
‘argument’ => ‘’,
‘signal’ => {
’ => ‘24af06e1’
},
‘tx’ => {
'
’ => ‘dfb9aaca’
},
‘action’ => ‘SetSpeed’,
‘name’ => ‘Speed 6’
};
$VAR1 = {
‘icon’ => ‘button_reverse’,
’ => ‘7496c838’,
‘argument’ => ‘’,
‘signal’ => {
'
’ => ‘ba47fcc6’
},
‘tx’ => {
‘_’ => ‘1ffc7e8e’
},
‘action’ => ‘ToggleDirection’,
‘name’ => ‘Reverse’
};

Out of curiosity, when you say in step 1 that “when you send commands” - is that with a direct cURL call, Postman, MisterHouse, or something else?
I first test every command multiple times with a raw cURL call from command line before I integrate with my HA (ISY in my case).
Though honestly I haven’t (yet) experienced either method ever giving me trouble as you describe. I’ll test more this evening.

Sounds like some of your requests are causing the HTTP server to get stuck. Can you provide what requests you’re making in part 1 so that I can reproduce this issue?

I used perl LWP::UserAgent to programatically get the information to send the command and manually built the URL with cURL, both ways have the same issue described in number 1. I always get a 204 response back from the Bond.

For issue 1, it was happening when I first started doing initial testing with cURL and sending single tx commands. Even after a reboot of the Bond, I would send a single tx command and get a 204 back. I tried many different speed commands but I think they all had the same result, below is the “Speed 1” command:
curl -H “BOND-Token: *************” -i http://192.168.1.5/v2/devices/4f0e7012/commands/3db887f6/tx -X PUT -d {}

For the timeouts described in #2, they seem to be random, it never happens in the same place and they usually succeed after 1 retry (at most 2).

204 status is expected for PUTs to a command’s tx endpoint, but it should also transmit the proper signal. Are you on the latest v2.6.7-beta firmware?

As for issue #2, I’ll try to stress test a BOND in a similar way to reproduce what you’re seeing. To help me narrow down the problem, does your BOND’s serial number start with a Z?

Mine is running v2.5.2

This is what it returns from the version call:
“target”:“zermatt”,“fw_ver”:“v2.5.2”,“fw_date”:“Thu Mar 7 19:54:03 UTC 2019”,“manufacturer”:“Olibra”,“model”:“BD-1000”,“branding_profile”:“O_BD-1000”

The serial starts with ZZBL…

I can send you the perl script I am using if you want it.

Just for comparison’s sake, that is the same firmware version I am running on my ZZ Bridge as well. Just confirmed both light control (on / off and dimming / stop dimming) as well as fan speeds 1 - 3 + fan off are all still being passed successfully from my keypads and switches utilizing the Local API commands, and the ceiling fan / light is responding.
It is hard to say objectively, but maybe it is a 1/2 to 1 second slower than it used to be under an earlier ZZ firmware?

Regarding #1, Today when I got home, I ran all the speed commands and the fan responded normally… I also pulled my complete bash history and ran through all the curl commands past the point where I started sending the tx commands when the fan was not responding and the fan responded as it is supposed to, so that does not seem to be the issue.

Is there any interaction with the cloud services when the local API is called? I was doing my initial testing on Sat morning 4/27 (when the fan was not responding), periodically when I would try to send a command from the Android app it would say “trouble contacting bond due to network issues” (or something like that). Even though it would say it was having network trouble, it would still send the command to fan. At the time I wasn’t having any Internet issues and the local network was fine as I was able to send local commands to the Bond without issue. Is it possible that this intermittent issue with the cloud service cause the issues I was seeing? Other than that I have no idea why it works perfectly today but not on Sat.

1 Like

I believe I’ve reproduced this. If I’m right it is due to a known issue where attempting to send a response via MQTT blocks a HTTP response. We’ve been working on fixing this for a few days, we’re nearing a solution, and a fix should come out in the next release.

Is there any interaction with the cloud services when the local API is called?

Yes. The BOND will at least attempt to talk to the MQTT server (you can configure MQTT so that the BOND doesn’t talk to our cload with a PATCH to api/mqtt, but I suspect this won’t solve the issue)

Is it possible that this intermittent issue with the cloud service cause the issues I was seeing?

I can’t say for sure but I have a suspicion that this is correct!

2 Likes