Intermittent availability

[BobFrankston]

Some devices aren't always available. It would be nice to have an "OK if not there" mode so I don't unnecessary warnings.

 

[lilyoyo1]

1 hour ago, BobFrankston said:

Some devices aren't always available. It would be nice to have an "OK if not there" mode so I don't unnecessary warnings.

 

You can disable the query at startup then you won't get warnings if they don't matter to you. 

If it's a device you know is in there and it's missing (you unplugged something purposely, you can disable the device itself

[larryllix]

You can disable the query at startup then you won't get warnings if they don't matter to you. 
If it's a device you know is in there and it's missing (you unplugged something purposely, you can disable the device itself

Hmmmmmm.... Individual device query at startup may speed boot times and offer some advantages. It would need to default to query at startup unless user locked out.

Sent using Tapatalk

[BobFrankston]

I still want querying when the device is available.

Speaking of which -- I notice if I send a rest command like DFON and then do a status call it doesn't get the ON status. Since Insteon commands are synchronous it should be possible to send the reported status. (Mentioning this here to avoid starting a new topic -- I'll work around).

[larryllix]

I still want querying when the device is available.

Speaking of which -- I notice if I send a rest command like DFON and then do a status call it doesn't get the ON status. Since Insteon commands are synchronous it should be possible to send the reported status. (Mentioning this here to avoid starting a new topic -- I'll work around).

Insteon devices do not work that way. Insteon devices report any changes to other devices.

If an Insteon device is not updating properly, then a link is missing from the device to your PLM, or you have a comm problem between devices.

Queries should never be necessary with Insteon, except when first booting up and then ISY is currently dumb, until told by other devices what to think.

Sent using Tapatalk

[BobFrankston]

In theory Insteon device to report to the PLM assuming that the PLM is properly updated but messages do get lost.

But that also raises the question of why a status after a command shows the old status.

 

[lilyoyo1]

44 minutes ago, BobFrankston said:

In theory Insteon device to report to the PLM assuming that the PLM is properly updated but messages do get lost.

Not understanding this. A properly updated plm wouldn't "lose" a message. Most likely there are comm issues and the plm simply didn't get the message

But that also raises the question of why a status after a command shows the old status.

1 of 2 reasons. Either an error with the ISY (first thing I'd check is firmware/UI) or your plm didn't get an acknowledgement which goes back to communication issues

 

 

[lilyoyo1]

1 hour ago, BobFrankston said:

I still want querying when the device is available.

 

You can't have it both ways. The whole purpose of a query to to show device status and disposition. 

[BobFrankston]

1. Things go wrong. Resilient systems tolerate failure. Messages get lost for many reasons.
2. Querying is fine - I don't need to be told about the failures when the device is not available

[BobFrankston]

A related point is that when I start a subscription and/or do a global status I want the current status but seem to be getting stale info. Not sure why.

[larryllix]

Your first post shows you are getting comm errors. This is typically dues to electrical noise interfering with your Insteon signals.

Insteon signals will try three times if they do not get a validation response from the target device. Every other Insteon dual band device in your system will also try to repeat and boost the signals by simultaneously transmitting to make the system more reliable. When you have a comm problem it needs to be found and fixed or it will likely get worse. Querying it again may work sometimes but cannot be relied upon.

I had very occasional comm failure in my system. When I got a new GDO last year with battery backup my system went to about 70% comm failures. I had to find it and the latest GDO was the clue. Then I discovered by unplugging my first GDO the problems cleared up. Two FilterLincs fixed that up. It isn't the motors in the GDOs...it's the electronics. This is common with the popular brand names, evidenced by many problems the same years back that I always ignored.

[BobFrankston]

I'm extremely familiar with the Insteon protocol and its failure mode. One reason I'm shifting away from Insteon is that there are such issues and the protocol is limited by its design point. I"m now trying to track down the status reporting inconsistencies.

 

[BobFrankston]

So you understand here are a sequence of messages

05-22 23:48:53.868        Sent(/rest/nodes/3B 28 3F 1/cmd/DFOF) OfficeMidFront
05-22 23:48:53.896        Sent(/rest/status/3B 28 3F 1) OfficeMidFront
05-22 23:48:53.968   GotStatus(OfficeMidFront, on) update
05-22 23:48:55.612   GotStatus(OfficeMidFront, off) watcher
 

I sent a DFOF and then asked for the status and was told the light was still on. I then got a message from my subscription saying it was off.

[BobFrankston]

For some reason,

 

 

 

 

 

4

Quote

Posted in Intermittent availability   35 minutes ago, BobFrankston said: In theory Insteon device to report to the PLM assuming that the PLM is properly updated but messages do get lost. Not understanding this. A properly updated plm wouldn't "lose" a message. Most likely there are comm issues and the plm simply didn't get the message But that also raises the question of why a status after a command shows the old status. 1 of 2 reasons. Either an error with the ISY (first thing I'd check is firmware/UI) or your plm didn't get an acknowledgement which goes back to communication issues Go to this Post Accept that I understand the Insteon signaling and PLM going back to at least 2005 in the SALAD days.  Also more than a fair amount of operating system work going back to the dawn of time(sharing)  ... but as an FYI all gear is new and/or certified by UDI and updated to 5x latest. The key point is that the response message showed the previous value but the subscription message showed the updated value. Indicates a race condition or something akin to that.

I"m not seeing your post

 

[lilyoyo1]

Having new devices, a certified ISY (all ISYs are certified) doesn't mean you can't have communication issues. That's akin to saying a new car can't have problems. It doesn't matter how many years you've used insteon. I've installed far more systems than I remember and still run into problems from time to time that wracks my brain to solve. 

If you're having intermittent device issues, it's either how you're writing your code or communication issues. Since the ISY is clearly coming back saying it's not communicating with stuff, The logical choice is communication issues. 

Since you have your own theories outside the advice that's been given here, there's not much we can do to help. Good luck with solving things

[MWareman]

So you understand here are a sequence of messages

05-22 23:48:53.868        Sent(/rest/nodes/3B 28 3F 1/cmd/DFOF) OfficeMidFront
05-22 23:48:53.896        Sent(/rest/status/3B 28 3F 1) OfficeMidFront
05-22 23:48:53.968   GotStatus(OfficeMidFront, on) update
05-22 23:48:55.612   GotStatus(OfficeMidFront, off) watcher
 
I sent a DFOF and then asked for the status and was told the light was still on. I then got a message from my subscription saying it was off.

You’d need to decode this on the wire - but your status request is extremely fast after the DFOF. Maybe the switch is not done processing it when the status request is received - and it pauses that to respond to the status before completing the DFOF... then it sends the subscription status after the DFOF completes.

To be honest, I’m not sure why you are requesting a status when you are going to be sent one anyway based on the link table...

[BobFrankston]

To respond to both previous questions.

First, I'm trying to understand the programming model of the ISY. From the description, it seems as if the messages to the PLM are being queued but not executed immediately so that a query request would see the previous state. That makes sense. The problem with waiting for a subscription response is that I'm considering a sending the messages directly from each switch (repurposed smartphones) and don't want to have them all listening to broadcasts from multiple sources. Given that, I can do my own dallying and delay the status query for a few seconds on devices that aren't listening for the broadcast. (At some point I'll write more about my system architecture and the goal of minimizing dependencies on any single point of failure).

As to communications errors. Just accept that they happen and that the entire Internet is based on only asking for best efforts rather than reliable messaging and we know how to deal with this. It can be handled gracefully in the Administrative Console by having a messaging window which shows the current list of failed messages and also by having a "last seen" column in the tabular view.

As an FYI I notice my earliest ISY backup is 2007 but I'm only now switching to making it my main interface for Insteon. One reason for the delay is the early limits on the API but, far more important has been the lack of graceful handling of limitations of the Insteon protocol and intermittent failures. The fatal limit is the assumption that devices respond synchronously. It limits scaling and the ability to add bridges. I'm now far less dependent upon Insteon wall switches.

 

[Michel Kohanim]

@BobFrankston,

ISY uses something called MessageHandler: since INSTEON does not have any IDs to track between request and response, we have devised an algorithm that, in 99% of the cases, matches a request with a response. This also means that ISY will block all other commands being sent to the PLM while it waits for the correct response. Almost synchronous but not 100%.

With regards to your other comments, I suspect you will be developing what's already in ISY. Communications issues are NEVER related to ISY. In more than 80% of the cases, it's the location of the PLM and other things on that outlet. In the other 20%, the majority is related to load or noise and 5% related to defective devices.

With kind regards,
Michel

[BobFrankston]

I'm not blaming ISY - just saying that whatever the cause communications failures happen and should be handled gracefully. Modal dialogues are not graceful.

When I originally did my PLM programming I had complex approaches to handle messaging and only later did I find out it was all very synchronous with immediate responses. Perhaps a message can sneak in through the PLM but that would be the exception. As bad as that is it does mean that you can provide a response to a command pretty quickly. But, for now, I'll just do a wait and query on my client devices to work around it.

[BobFrankston]

What is not acceptable is that the model dialog rips control from my while in the middle of doing something and says that the ISY is more important than anything else in the world. No, it is not. That is a priority bug and a terrible UX. I don't care at all that some messages get lost but I do want to have the ISY attempt once in a while. But it must not annoy me! 

I'm running v.5.015A.

Please tell me when the bug is fixed.

Now back to what I was trying to do (ironically, add support for the ISY to my web app).

 

[lilyoyo1]

1 minute ago, BobFrankston said:

What is not acceptable is that the model dialog rips control from my while in the middle of doing something and says that the ISY is more important than anything else in the world. No, it is not. That is a priority bug and a terrible UX. I don't care at all that some messages get lost but I do want to have the ISY attempt once in a while. But it must not annoy me! 

I'm running v.5.015A.

Please tell me when the bug is fixed.

Now back to what I was trying to do (ironically, add support for the ISY to my web app).

 

What you are experiencing is not a bug. It is how the ISY was designed for its end users. IF you want custom code to fit your needs then you need to create YOUR OWN SOFTWARE.  Then you can have it work and do exactly what you want it to do and how. There are other controllers out there

[BobFrankston]

Your arrogance is amazing. All you need do is add a flag to control that behavior. Why are you treating users as your enemy?
 

[lilyoyo1]

4 minutes ago, BobFrankston said:

Your arrogance is amazing. All you need do is add a flag to control that behavior. Why are you treating users as your enemy?
 

Im not treating anyone as my enemy nor am I arrogant. I am however a straight shooter. I just have a thing against people coming onto forums and blaming others for their shortfalls. You were given a way how to work around how UDI decided to run their system and instead of using it, you try to blast them like they owe you something. if you dont like how they operate try something else or write your own code. 

[BobFrankston]

I apologize if my use of a big red font set you off but taking control of the keyboard on a shared system does go against basic guidelines for applications. How would you feel if you were trying to get your thoughts together and suddenly found yourself in another window? Like when I was taking a picture and stepped back - took me a few seconds to realize the blue around me was the pool I stepped into.

What I'm asking for is pretty trivial - a flag to prevent seizing control. That's why I felt it was OK to ask for it -- a win for you in improved experience with very litlte coding?
 

[BobFrankston]

As an FYI -- just moved all my Insteon code to UDI -- eliminating maybe thousands of lines of Insteon and PLM support. Much simpler to use your API with shims so browser apps can have direct control.