Issues with AK Bond installation

[alexbk66]

What is the delay parameter doing? Is it waiting between sending an action (as in a device state change request) and polling for the resulting status (see that it changed) or is it waiting between requesting the status and reading the socket for the status response.

The former.
Read socket delay is set to 30 sec, which is sufficient. So your issues are not caused by this timeout.

If you Google for 'Error getting response stream (ReadDoneAsync2): ReceiveFailure' - it's known Mono issue

[alexbk66]

I think the issue is with the delay between the socket send "status request" and the socket read to get the "status response" being too short. You may need a delay between sending a device change request and sending a status request as well to actually see the change take place, but I think the com error could be caused by trying to read the socket too soon after you send the status request. I may be off base here ...

Possible. Since I'm using RestSharp library - I need to dig into their code. It could depend on a lot of things in the network stack...

[alexbk66]

One minor issue that has only to do with the trusted state access you added. It appears you only get that state on AK Bond start up so if the Bond App changes that state while AK Bond is running AK Bond does not update to show the correct state. I see that you can change the state using the AK Bond config pages and that seems to work properly.

That's true, but I don't want to poll for settings change as well. How often do you modify the Bond settings? And I always prefer to move most settings form the app to HS, so you don't need to use the app at all.

[CJMH]

Regarding the trusted state issue with the app and HS. I don't really care. I just thought you should know if you did not already as it may confuse someone else. Personally, I think it is a mistake to allow the Bond to be in a non-trusted state. The developers of the Harmony Bridge seem to have agreed with me on that.

Regarding the rec error. It may be a known bug in Mono, but it doesn't seem to effect anything else in HS3 that I can see and HS3 does a lot of network communication. I never see any errors or problems with anything else that uses sockets. So I assume there is a workaround.

I had a Honeywell thermostat plugin at one time that talked to the Honeywell cloud server and I never saw any rec errors from it. The only problem with that plugin was that the developer reversed engineered the Honeywell protocol and Honeywell kept changing it, so his plugin would work for a month or so and then stop working and he would have to reverse engineer it again and make the appropriate changes to his plugin.

And more to the point, why does turning on the log fix it? And how can that be simulated with the log off?

[alexbk66]

I never see any errors or problems with anything else that uses sockets. So I assume there is a workaround.

I had a Honeywell thermostat plugin at one time that talked to the Honeywell cloud server and I never saw any rec errors from it. The only problem with that plugin was that the developer reversed engineered the Honeywell protocol and Honeywell kept changing it, so his plugin would work for a month or so and then stop working and he would have to reverse engineer it again and make the appropriate changes to his plugin.

And more to the point, why does turning on the log fix it? And how can that be simulated with the log off?

Probably you didn't see any errors because most developers don't ever implement error handling. I can disable error logging - and you would never know that there's a problem.

Regarding last point - I'll think about it

[alexbk66]

Most common error you see in HomeSeer - "Object reference not set to an instance of an object" - that's an error caught by HomeSeer itself, not plugins. And nobody knows - what object, what reference?

[CJMH]

You have a lot of experience with developing plugins for HS3. I have none, so I defer to your wisdom here.

It is true that the other than the logging the errors and seeing the AK Bond devices go to an unknown state then back to normal, the com errors do not seem to make any difference.

However, the error reporting of these com errors does create a lot of unnecessary log entries given that it does not effect the way the plugin works. How about having a config page switch that allows these particular com errors put the to get logged (and put the device into an unknown state) or not? That way your customers could decide if they want to see all these errors their logs and the side effects in the devices or not.

Thanks again for your efforts and patience with me.

[alexbk66]

However, the error reporting of these com errors does create a lot of unnecessary log entries given that it does not effect the way the plugin works. How about having a config page switch that allows these particular com errors put the to get logged (and put the device into an unknown state) or not? That way your customers could decide if they want to see all these errors their logs and the side effects in the devices or not.

I'm Googling now, the error does come from Mono source - that's why on Windows there's no such error.



And because the request has been sent, but reply not received - it's unknown what to do next.

What I will do - catch this particular error (ReceiveFailure) then close the socket and create a new one. Next question is - how many times to retry? Otherwise may stuck in infinite loop.

[alexbk66]

So, version 3.0.0.23 in Beta. In case of ReceiveFailure - I log the 'log', not 'Error' and delete Socket. See how it goes.

[CJMH]

Ok trying now ....

Assuming the receive failure is not permanent when the Bond is connected a subsequent read would work, how about this where 'n' is a settable parameter that allows for the number of retries. Forgive my rustyness on C#.

nread = 0;

for (i=0; i<n && nread == 0; i++) {
wait (100milliseconds)
nread = RequestStream(....)
}

if (nread == 0 )
throw ....

So far 23 is working without issues. I assume the side effect of ignoring the error is the status is not updated until the next poll. I have not seen anything in the log yet about the rec error happening, but do I have to have logging on to see it or does that particular "log" of the problem bypass the log switch?

I will keep watching and let you know more in a while ....

[CJMH]

Its been running for 1/2 hour and I have not seen anything in the log. I would have expected to see you log a normal log that the receive failed at least several time by now. If I have to have logging on remember that with logging on I never saw the come error, so that would defeat the purpose of testing that way.

[CJMH]

One other thing .... you probably already thought of this, but you may want put the for loop around creating a new socket and making the whole status request again.

Another idea would be simply ignore that particular error all together as it will correct itself (usually) on the next poll. I assume that is what you are doing now?

[CJMH]

Its been running for over an hour now without incident or log entry (except for normal entries for device changes).

[alexbk66]

Another idea would be simply ignore that particular error all together as it will correct itself (usually) on the next poll. I assume that is what you are doing now?

Yeah, just another thing I can do - when this error happens, I can set the timer to 1 sec instead of usual (i.e. 10 sec) to minimise the delay. But I think - the simpler - the better.

[CJMH]

KISS principle ... Agreed! Still no problems after 2 hours!