Issues with AK Bond installation

[CJMH]

Now that the plugin is working reliably I can tell you more about the double light situation. I can say it is very non-intuitive (and somewhat stupid), but I see where they think it might works as advertised. The "Light" control seems to control both the "UpLight" and the "DownLight". So if the "Light" is off, so are both lights no matter what the state of the "UpLight" and "DownLight". So if the state of the the "UpLight" and "DownLight" are "ON" (even though the physical lights are off) and I click the "TurnLightOn" button, both lights come on and the "Light", "UpLight", and "DownLight" icons now all show "ON". If I click the "TurnLightOff", both physical lights go off and the "Light" device icon shows "OFF", and the up/down light icon still show on. So the up/down light devices are a sort of child device of the "Light" device and simply indicate what the last state of the their respective device was/is regardless of the whether the physical device is on or not. However, this is only true when using the "Light" controls.

Where it gets weird is the following scenario:

Both up and down light icons show ON and the "Light" icon shows OFF, then I click the "TurnUpLightOff". The "Uplight" icon goes OFF, the "Light" icon goes "ON", and the "DownLight" icon stays on. However, the physical up light is now on and the physical down light is still off. The icon status is now wrong.

Then if I click "TurnLightOff" the up and down lights are now on and the status icons show that the "Light" and "Uplight" are off and the "DownLight" is on. Again out of sync with the actual lights.

Even if you are sending the wrong command to the BOND, the state should reflect the actual state of the lights, so they have a problem with their firmware/API (at least with 2.10.8)

I know this is not your problem, but thought you should know that at least Bond firmware 2.10.8 does not work correctly no matter what Bond is saying. I have asks them how I can upgrade to 2.10.15 to see if that makes any difference, but I am not holding my breath from reading the thread you had with Jacob.

BTW, still no crash ....

[CJMH]

I changed the "Trust tracked state" to ON for the A1a fan in the Bond App and now things work correctly. This may also be a problem for fans with one light, but I don't have one so I can't test it. Do you have API access to an indication of whether the FAN is in the "Trust tracked state" mode or not.

You could also implement this "trust" state paradigm in your plugin by checking the state(s) before sending a command.

1) Check the current status of the up/down light and not send the up/down command to the Bond if action does not change the state of the up/down light (i.e. ignore the action).

2) Send a command to turn the "Light" device ON (if it is OFF) before sending any commands to change to the up/down light device state. Then if the up/down state change was to turn the up/down light off and the "Light" device was originally OFF, you could then send the command to turn the "Light" device back OFF.

Bond should really fix this for when the "Trust tracked state" is OFF, so I am not sure you should do any of what I am suggesting, but it would not hurt even if Bond does fix their firmware/API. Also, Bond may believe this is the way it should work when "Trust tracked state" is OFF, but they would be wrong IMHO as API calls can get the state out of sync and there is no way that is a good thing.

I heard back from Bond and they said I would have to wait for the firmware 2.10.15 update which they said would occur in the next few days, but my guess is that nothing will change.

[CJMH]

I can fight this battle with Bond, but not being a BOND API software developer, they may ignore me and I would only be guessing about how the API works, whereas you have all the API knowledge. Let me know if I can help with this in any way. Or you could just tell people they have to set the "Trust tracked state" to ON in the Bond app for fans that have a toggle light(s).

[CJMH]

In the mean time ... any thoughts on why the Update interval is random from nearly instantaneous to 5 or so seconds?

[CJMH]

I still think Bond is not working properly with the API even in the "Trust tracked state" ON. I did the following:

"Light" and "DownLight" are OFF, "UpLight" is ON: Physical lights are both OFF. Click "TurnLightOn" and only the bottom light is physically turned on, yet the status shows "Light", "UpLight", and "DownLight" are ON. So Bond incorrectly assumed the uplight status was correct (I assume) and did not turn on the uplight even thought all lights were off. I understand if you don't want to mess with this until Bond gets it straighten out. I will send a support request to them, but it would be good to know more about what you are doing in these cases so I can be clear with them. Do you simply send the associated command to bond for the control button click? Thanks ...

[CJMH]

Sorry for all the posts. Ignore them and read just this one. I gave up on the two light fan issue and removed that fan and added it back as a one light fan (A1) and it works fine that way. We never use the up light anyway. I may try it again when the 2.10.15 is released, but for now I have the information I need to move forward.

However, it is imperative (for both AK Bond and Google Home) that one sets the "Trust tracked state" on in the Bond App. Before I set that, if I told Google to turn off the light when it was already off, Bond would turn the light back on.

So the two remaining issues are

1) The update rate issue (does not honor the Config Page setting)

2) The receive errors

If issue 1) is fixed, perhaps issue 2) will be also.

Thanks!

[alexbk66]

In the mean time ... any thoughts on why the Update interval is random from nearly instantaneous to 5 or so seconds?

I suspect this is caused by the slow Raspberry PI - it takes longer to process requests - so it sends new request after it's finished with previous.

But that's my guess, nobody had this issue. Can you check CPU usage? I think it's htop command on Linix.

[alexbk66]

I still think Bond is not working properly with the API even in the "Trust tracked state" ON. I did the following:

"Light" and "DownLight" are OFF, "UpLight" is ON: Physical lights are both OFF. Click "TurnLightOn" and only the bottom light is physically turned on, yet the status shows "Light", "UpLight", and "DownLight" are ON. So Bond incorrectly assumed the uplight status was correct (I assume) and did not turn on the uplight even thought all lights were off. I understand if you don't want to mess with this until Bond gets it straighten out. I will send a support request to them, but it would be good to know more about what you are doing in these cases so I can be clear with them. Do you simply send the associated command to bond for the control button click? Thanks ...

May I ask you to copy your comments to https://forums.homeseer.com/forum/wi...ight-confusion

To keep it separate and make it easier for others to track

[alexbk66]

I still think Bond is not working properly with the API even in the "Trust tracked state" ON.

I can change logic in my plugin to make it work properly, I'm just not sure what exactly users prefer, i.e. hide the 'Light' device all together?

[CJMH]

I suspect this is caused by the slow Raspberry PI - it takes longer to process requests - so it sends new request after it's finished with previous.

But that's my guess, nobody had this issue. Can you check CPU usage? I think it's htop command on Linix.

Mono is using about 24% of the processor while AK Bond is running. If I disable AK Bond, mono's usage drops to 6%. I don't think the issues is a slow processor unless you are processing huge amounts of packet data which would not seem likely. I think it is more likely that for some reason the timer is not pacing the polling requests and they are running out of control. Not sure how to test for that.

I assume the Bond Bridge communication is fairly low bandwidth. Especially if the polling period is set to 10 seconds. If processing power was the issue why would clicking an action button on a Bond device in HS3 result in a nearly instantaneous response (much less than one second) on the Bond app running my android phone? The communication path there is from the ZEE S2 to the Bond Bridge and then to the Android Phone over the local network (local I assume). If that can be instantaneous how could polling every 10 seconds overburden the processor? And if the processor is overburdened why am I not seeing other event processing slow down on HS3? Processing from a multi-tap switches is instantaneous with AK Bond running. The path there is a rather slow Z-Wave serial RF com path (something like 43 to 100 KBaud I believe) from the switch to the ZEE S2 and then HS3 has to process the scene code it receives and send a Z-Wave RF signal to the specified device in the event I set up. This is done at the event processing level in HS3 rather than in C# which I assume is what the plugin is using. So event processing should be even slower (although I am not sure exactly how event processing is handled in HS3). In any case, all this is working without any issue or slowness while AK Bond is running taking up 24% processor resource.

Is there anything I can do to help debug this issue on my end?

Thanks!

[CJMH]

You said that no one else is reporting this problem. Is anyone else running on a PI or ZEE S2 based on PI? It seems I am the first to try this on a PI based system based on the initial issue I had.

[CJMH]

I looked at processor utilization again and I see it jumps around a lot if I sample it over and over, so my earlier report is not really correct. I restarted AK Bond. If I sample the utilization as fast as I can (about 5 or so times per second) the Mono utilization is generally below 10-15%, but occasion it goes much higher, but only for a very brief amount of time. I see this kind of jumping around whether AK Bond is running or not. I don't see how polling every 10 seconds could possible cause the CPU to bog down for the whole 10 seconds so it ends up poll twice in a row. I certainly don't see that in the processor utilization or it effecting event processing in HS3 which it doesn't.

I am at your disposal for any testing/debugging I can help with on my end.

[alexbk66]

Mono is using about 24% of the processor while AK Bond is running. If I disable AK Bond, mono's usage drops to 6%. I don't think the issues is a slow processor unless you are processing huge amounts of packet data which would not seem likely. I think it is more likely that for some reason the timer is not pacing the polling requests and they are running out of control. Not sure how to test for that.

I assume the Bond Bridge communication is fairly low bandwidth. Especially if the polling period is set to 10 seconds. If processing power was the issue why would clicking an action button on a Bond device in HS3 result in a nearly instantaneous response (much less than one second) on the Bond app running my android phone? In any case, all this is working without any issue or slowness while AK Bond is running taking up 24% processor resource.

I guess you are right, but I had to check. Just FIY, when the plugin sends the command to Bond app (yes, it's local) - the data is very small. When it's asking for status - it's getting much more. But again, I don't think it's an issue.

BTW, on Linux it also logs to the console window - this can be slow too - just the console I/O. For real time apps if I need console output - I usually queue it - and the separate thread is reading from the queue.

[alexbk66]

I looked at processor utilization again and I see it jumps around a lot if I sample it over and over, so my earlier report is not really correct. I restarted AK Bond. If I sample the utilization as fast as I can (about 5 or so times per second) the Mono utilization is generally below 10-15%, but occasion it goes much higher, but only for a very brief amount of time. I see this kind of jumping around whether AK Bond is running or not. I don't see how polling every 10 seconds could possible cause the CPU to bog down for the whole 10 seconds so it ends up poll twice in a row. I certainly don't see that in the processor utilization or it effecting event processing in HS3 which it doesn't.

I am at your disposal for any testing/debugging I can help with on my end.

You mean that somethink else is using the CPU - that's why the AKBond timer can't cope? May be. I have a lot of CPU usage by Z-Wave plugin sometimes, even if it's not doing anything. Also reported by users in the forum.

May be try temporary disabling Z-Wave plugin?

Also, I can increase max polling rate to say 20 sec. to see if polling at least stabilizes.

And Bond also supports Bond Push UDP Protocol (BPUP) instead of polling, but it's pretty new and still in Beta.

[alexbk66]

May be it's not CPU, but RAM? Can you monitor RAM usage?

Also, when you enable logging - it's writing a lot to HS DB, so there's also disk I/O involved.

May be disable logging and verify how long it takes to update HS device when you click buttons in Bond app.

But to get more real-time response - you need to use HSTouch - it's more immidiate. Using HS web control panel isn't determenistic - they also use timer and AJAX callback.