simplextech Posted February 18, 2019 Posted February 18, 2019 Being new to Insteon I'm trying learn as I go. So if I missed this and it's in a wiki or document some place please educate me. I have a recurring issue that appears to be messages not transmitting or being received? I have a program that is very simple Deck Lights-On - [ID 001B][Parent 001A] If 'Living Room / Door Sensor / living-room.door-Opened' Status is On Or 'Dining Room / Motion Sensor / dr.Motion-Sensor' Status is On Or 'CL Bedroom / Door Sensor / cl.room.ext.door-Opened' Status is On Then Set 'Deck / Scene / All Deck Lights' Fast On Else - No Actions - (To add one, press 'Action') Most of the time this works. Sometimes very slow to respond (delay) other times it seems reasonably quick and then there's the problem of nothing happening. Just nothing. I stand with the door open waiting and nothing. I close the door and then open the door again and it works. I can open the event viewer and go back and look at the data but unless I see something obvious (fail, error, warning, etc) what should I be looking for to try and diagnose this? I know they are open/close sensors (door sensors, contact sensors) and they are RF but there are two dual-band switches six feet away. An interesting phenomenon is that when I started with Insteon everything was very quick to respond and I only have a couple of plugin modules. Now I have migrated all of my z-wave switches to Insteon switches and things are SLOW. Ideas?
kclenden Posted February 18, 2019 Posted February 18, 2019 First thing I would do is change from using "Status is On" to "is switched On". In the former case, the ISY is responsible for maintaining the status of the device and then only taking action if the status changes. The ISY needs to see every ON and OFF from the device in order to know when its status has changed (e.g. if it misses an OFF then it will do nothing on the next ON). In the latter case, the ISY is simply looking for an ON from the device and doesn't care whether it ever sees an OFF. In theory, I would think that an ISY would react faster to "is switched On" than it reacts to "Status is On" but I don't know if that's actually true, or even if it was true whether it would be noticeable. I use a special state variable to track code execution. I call it sCodeTrack. Right before the code I want to track, I set it to a unique value, immediately followed by setting it to 0. In the Event Viewer, you'll see "[VAR 2 y] z" where y=the variable ID and Z=the value to which it was set. It's important to set it to 0 because the ISY will only show you a change in variable value within the Event Viewer (i.e. change from 0 to 2 will show up, but change from 2 to 2 will not). This not only allows you see if specific code runs, but also whether it ran before or after other code you're tracking.
simplextech Posted February 18, 2019 Author Posted February 18, 2019 10 hours ago, kclenden said: First thing I would do is change from using "Status is On" to "is switched On". I've been wondering about this myself. I've tested both ways and there's no perceivable difference that I can tell. 10 hours ago, kclenden said: The ISY needs to see every ON and OFF from the device in order to know when its status has changed (e.g. if it misses an OFF then it will do nothing on the next ON). This fills in a gap of knowledge for me and could explain some things. This gives more clarity around why it should be "switched on" and not use status to try and catch all of the messages. 10 hours ago, kclenden said: I use a special state variable to track code execution. I call it sCodeTrack. Right before the code I want to track, I set it to a unique value, immediately followed by setting it to 0. I'll have to implement this. I use state variables for other programs. I think I'll need to begin tracking each program with state variables. Is there a log available at all that shows program execution and times besides the summary view? It would be nice to have a debug method to see if programs are executed or not when there's a problem to be able to isolate if it's a communication issue. On to the other part of the question. What's a good/best method of checking/determining communication issues? I've read about using Filterlinc's to prevent problems from common things like UPS's and such and larger appliances. It seems there's no good method of determining a noise maker other than shutting off the power and testing and sometimes that's not possible. Is there another method to troubleshoot/isolate noise? Any test tools available? In the Z-Wave world I have tools like Z-Wave Toolbox or the Certified Installer's Toolbox I can use. Anything like that for Insteon?
Michel Kohanim Posted February 18, 2019 Posted February 18, 2019 @simplextech, There's definitely a perceivable difference between using status vs. control. Especially, and as @kclenden suggested - and specifically with respect to sensors - if the sensor is triggered multiple time before its status changes, then status will not trigger the program but Control does. This may not apply with door sensors but I always recommend using control for sensors since, otherwise, you will miss events. With kind regards, Michel
simplextech Posted February 18, 2019 Author Posted February 18, 2019 3 minutes ago, Michel Kohanim said: @simplextech, There's definitely a perceivable difference between using status vs. control. Especially, and as @kclenden suggested - and specifically with respect to sensors - if the sensor is triggered multiple time before its status changes, then status will not trigger the program but Control does. This may not apply with door sensors but I always recommend using control for sensors since, otherwise, you will miss events. With kind regards, Michel I think this would be good info to have in the wiki somewhere for new Insteon users? I was looking to find this type of info and I either overlooked it or something but I didn't find it. I'm going through and changing all sensors to be "switched on" to use the control vs status.
Michel Kohanim Posted February 18, 2019 Posted February 18, 2019 @simplextech, Did you also peruse the cookbook? With kind regards, Michel
simplextech Posted February 18, 2019 Author Posted February 18, 2019 10 minutes ago, Michel Kohanim said: Did you also peruse the cookbook? Yes I have been... it's large! The info may be in there... perhaps a sticky thread with top highlights of recommendations for general things new users should be aware of? Like differences between status vs control and when each should and should not be used?
palayman Posted February 18, 2019 Posted February 18, 2019 46 minutes ago, Michel Kohanim said: @simplextech, There's definitely a perceivable difference between using status vs. control. Especially, and as @kclenden suggested - and specifically with respect to sensors - if the sensor is triggered multiple time before its status changes, then status will not trigger the program but Control does. This may not apply with door sensors but I always recommend using control for sensors since, otherwise, you will miss events. With kind regards, Michel It took a while for this to sink in with me as well. Perhaps in a future version of the admin panel state variables and other status changes that will trigger a revaluation of the if statement could be shown in a different color (red!) than items that won't.
larryllix Posted February 18, 2019 Posted February 18, 2019 17 minutes ago, palayman said: It took a while for this to sink in with me as well. Perhaps in a future version of the admin panel state variables and other status changes that will trigger a revaluation of the if statement could be shown in a different color (red!) than items that won't. There is a "feature Request" thread that UDI actually reads.
kclenden Posted February 18, 2019 Posted February 18, 2019 1 hour ago, palayman said: Perhaps in a future version of the admin panel state variables and other status changes that will trigger a revaluation of the if statement could be shown in a different color (red!) than items that won't. I like that idea, though it would then create regular questions about what the color red means in IF statements. ?
simplextech Posted February 18, 2019 Author Posted February 18, 2019 12 minutes ago, kclenden said: I like that idea, though it would then create regular questions about what the color red means in IF statements. ? Could be answered in the sticky thread of best practices / common questions
kclenden Posted February 18, 2019 Posted February 18, 2019 1 minute ago, simplextech said: Could be answered in the sticky thread of best practices / common questions Yeah, but who has time to read all of that when there's a cool ISY and lots of fun devices to be programmed? ?
larryllix Posted February 18, 2019 Posted February 18, 2019 I have the same concern that information isn't available and where I want it when I want it. However, like most other smart things these days, who has the time to read and remember a 52,857 page manual now? Even MSDos v1.0 came with a what? 857 page hardcopy manual. It's definitely a problem with things becoming so big and virtual. Have you seen the wiki lately? It's getting organised and looks much better than 3 years ago, 3 months ago, 5 minutes ago!
simplextech Posted February 18, 2019 Author Posted February 18, 2019 The wiki and I are quite familiar with each other However there are things that are either not there yet or through organization not easily find-able and mediawiki has a terrible search capability. Some examples of some common things that are good to know for beginners to ISY... The control vs status for programs Device Naming Scheme 3rd parties (Mobilinc, Agave) do nothing with the folders and "room" presentation is a hit or miss ISY Web interfaces HAD uses the folders for rooms but UDajax does not so using UDajax can be a problem if devices have the same name in different rooms/folders I'm sure I have more questions that are really really basic for someone who has used the system for a while. In many ways I can see some people not asking for fear of being judged as being "dumb" but I will ask.
larryllix Posted February 19, 2019 Posted February 19, 2019 Yeah. It's a catch-22. When you are new you understand the conplexity of not understanding WTH is going on and could write a good starter manual but don't know enough. Once you are more familiar with ISY nuances you could write a better wiki but the beginner problems seem so ridiculously simple you wouldn't bother to write them down. The wiki is definitely a work in progress and once it is polished and well finished things will have changed again so most of it will be obsolete. ISY forums rule forever!
simplextech Posted February 19, 2019 Author Posted February 19, 2019 4 minutes ago, larryllix said: The wiki is definitely a work in progress and once it is polished and well finished things will have changed again so most of it will be obsolete. ISY forums rule forever! In my view this is the power of forums. Having the communication and moderation aspects to keep things up to date and for people like me to be able to ask a question when something seems straight forward but really it works differently than what you may think.
palayman Posted February 19, 2019 Posted February 19, 2019 7 hours ago, larryllix said: There is a "feature Request" thread that UDI actually reads. Do you know where to find it? Tried a few searches (made sure to wait 2 seconds between them) with no luck. Couldn't find it in the wiki either.
larryllix Posted February 19, 2019 Posted February 19, 2019 1 hour ago, palayman said: Do you know where to find it? Tried a few searches (made sure to wait 2 seconds between them) with no luck. Couldn't find it in the wiki either. Browse Tab|Product Requests https://forum.universal-devices.com/forum/6-product-requests/
simplextech Posted March 1, 2019 Author Posted March 1, 2019 On 2/17/2019 at 11:49 PM, simplextech said: Being new to Insteon I'm trying learn as I go. So if I missed this and it's in a wiki or document some place please educate me. I have a recurring issue that appears to be messages not transmitting or being received? I have a program that is very simple Deck Lights-On - [ID 001B][Parent 001A] If 'Living Room / Door Sensor / living-room.door-Opened' Status is On Or 'Dining Room / Motion Sensor / dr.Motion-Sensor' Status is On Or 'CL Bedroom / Door Sensor / cl.room.ext.door-Opened' Status is On Then Set 'Deck / Scene / All Deck Lights' Fast On Else - No Actions - (To add one, press 'Action') Most of the time this works. Sometimes very slow to respond (delay) other times it seems reasonably quick and then there's the problem of nothing happening. Just nothing. I stand with the door open waiting and nothing. I close the door and then open the door again and it works. I can open the event viewer and go back and look at the data but unless I see something obvious (fail, error, warning, etc) what should I be looking for to try and diagnose this? I know they are open/close sensors (door sensors, contact sensors) and they are RF but there are two dual-band switches six feet away. An interesting phenomenon is that when I started with Insteon everything was very quick to respond and I only have a couple of plugin modules. Now I have migrated all of my z-wave switches to Insteon switches and things are SLOW. Ideas? In a continuation of my testing with this simple program to turn on a few lights.... The program is quoted above and as before and for quite a while the issue was that the lights would only come on after a long delay or not at all.... Things tried: Cut the program down to just basics with no schedule or anything fancy dug through logs checking communications Per suggestion added a wait 1 second to the program Changed the location of the PLM to a different outlet Results were always the same. Slow to react IF it worked at all. The success rate of the program running was about 50% success. NOT ACCEPTABLE. So for giggles I paid for the HomeSeer Insteon plugin from Mark (excellent plugin BTW) and I set that up. At first I just migrated the two door sensors and the set of light switches I wanted to control. Speed: EXCELLENT almost as fast as a direct link Delay: occured twice of less than 1 second throughout the entire day/night of testing/validation yesterday 100% success rate of the lights turning on as they are supposed to. Differences are HomeSeer using Mark's Insteon plugin and a different PLM. I used a USB PLM with HomeSeer vs the Serial PLM used with IYS. Same outlet was used. Bad PLM? Maybe but why was it just affecting response time, function through programs and not any manual activity or "scene tests"? Both PLM's are brand new and purchased in the last month along with my ISY and all Insteon equipment. Using the HS3 plugin I can see my communication "status" and all communications are Excellent with some failures but not a large amount as I suspected. Next step. I moved EVERYTHING from the ISY to HomeSeer for the test to see if the difference was having a small number of devices in the communications mix versus a larger number ~50 (Insteon) devices. There was no difference to the speed or reaction timing of anything with the added numbers of devices. End summary: The ONLY differences in this are the PLM and the Controller (ISY vs HomeSeer and their respective hardware). Possible flaky PLM? Or is there some problem with the 5.0.14Beta firmware or is the ISY having a hard time resource wise? I don't know there's limited capabilities for troubleshooting or diagnostics besides the event log. With the suggestion of adding a 1 second wait for programs to handle retries and not miss things leads me to think this is an ISY resource limitation of not processing messages fast enough. But I don't know and I'm new to using the ISY. So far the results using HomeSeer vs ISY are night and day in all of my "programs" executing extremely fast with no delays. My hope is someone else may have some more information that may shed some light on maybe provided a "Why" to all of this.
Michel Kohanim Posted March 1, 2019 Posted March 1, 2019 @simplextech, 1. On our email exchange, you mentioned that you didn't have this issue with another sensor. Did you try my suggestion: swapping the sensors? 2. Although in the thread it seems that you are now using Control, but the code shows Status. So, which one are you using? Can you paste the program as you have it now? 3. IMHO, rather than spending time migrating things back and forth, may I humbly suggest: either move to HS altogether or, if you are staying with ISY, most important pieces of information are those in the Event Viewer. i.e. are you getting DON events? When do you get them? Is DON sent to the scene? 4. Since I don't know how HS works, I am concerned that your whole configuration is now corrupted with links to the USB PLM. Hopefully you can clean them up as this just adds yet another variable to the whole mix. i.e. if you want to move back to ISY, it's best to factory reset all your devices, remove them all from ISY, and then add them back With kind regards, Michel
simplextech Posted March 1, 2019 Author Posted March 1, 2019 2 minutes ago, Michel Kohanim said: @simplextech, 1. On our email exchange, you mentioned that you didn't have this issue with another sensor. Did you try my suggestion: swapping the sensors? 2. Although in the thread it seems that you are now using Control, but the code shows Status. So, which one are you using? Can you paste the program as you have it now? 3. IMHO, rather than spending time migrating things back and forth, may I humbly suggest: either move to HS altogether or, if you are staying with ISY, most important pieces of information are those in the Event Viewer. i.e. are you getting DON events? When do you get them? Is DON sent to the scene? 4. Since I don't know how HS works, I am concerned that your whole configuration is now corrupted with links to the USB PLM. Hopefully you can clean them up as this just adds yet another variable to the whole mix. i.e. if you want to move back to ISY, it's best to factory reset all your devices, remove them all from ISY, and then add them back With kind regards, Michel Swapping sensors that are 6-8 feet away for RF issues seems pointless. Especially when in direct link with a scene things work 100%. So it would be a COMM issue from Sensor to PLM. However yes a sensor swap was performed and same reults. With more testing the other door was identified of having the same issue with the original sensor. This door is not used as frequently. Upon further testing the other door to the garage controlling lights also had the same issue . So I tested with 3 different sensors all operating lights and same "issue" occurred when using programs. When using direct link with a scene no problem other than you can't keep the lights on because of the DOF when the door is closed. I have several threads on this issue. I changed to "Control" as that is the appropriate/recommended method for the trigger. Nothing left to paste at this time Humbly suggesting that I just move to HS? Well this was acquired for testing/validation for use in recommending and possibly even personal use if things worked out well. But if the suggestion is to move to HS for a better experience you would know more than I do. As to the questions, yes I was getting the DON events so the Insteon network was working. The logs and events show everything was working as it should and those logs are scattered in a couple of threads on this forum and it was suggested to add a synthetic "Wait" to the program as if the ISY couldn't handle the traffic flow and they were "colliding"? So the wait was added/tested with no improvement. When I moved things to HS devices were reset. I'm not concerned about "keeping" things between the systems so things are reset moving back and forth. They have all been removed from ISY, reset and added to HS. They were originally only in ISY and I was having these weird issues which led to wondering where the problem was as the event log shows all of the DON/DOF correctly all network traffic was flowing correctly. Ultimately it "looks" like there is a issue with the "program" execution. Traffic is good, messages are received but not acted upon timely or at all in most cases. Frankly @Michel Kohanim I'm quite bothered by your suggestion to "either move to HS altogether". Coming from UDI I would think it would be of interest to see functional comparative data between a possible competitor when on the verge of a major firmware release of 5.0.14 and wanting to see if there are any outlier issues. I do plan on testing this for a few more days within HS and seeing what the results are before making a decision on which system I prefer to run based on real world results of speed and reliability.
Michel Kohanim Posted March 1, 2019 Posted March 1, 2019 @simplextech, I do apologize for offending you. I have never used HS so I have no clue what's best for your use cases. For me, any type of comparison is pretty much pointless since it deflects from finding the root cause. The only way comparing with HS would be of any benefit to us is if we go buy an HS, reverse engineer, and then try comparing and contrasting how we do things internally. And, unfortunately, that's not how we operate. The fact that you are saying that the programs do not work 50% of the time is quite suspect and, without seeing the traffic (Event Viewer), and the actual program, it would be impossible to debug. With kind regards, Michel
simplextech Posted March 1, 2019 Author Posted March 1, 2019 The purpose of bringing HS into the mix is: I have it at my disposal and I can run Insteon with it. It adds another controller for use with cross reference. If the problem stays the same it's the network right? If the problem goes away (which it has) It's the PLM It's the controller It's the program The final iteration of the program that was being tested used the "Switched On" per recommendations and was reduced down to only the one door sensor as the trigger. My current suspicions are: PLM difference Serial PLM rev 2.4 (I don't have a spare serial plm to compare with either) USB PLM rev 2.3 Controller difference HomeSeer with Insteon plugin ISY firmware 5.0.14Beta If this was a PLM issue I think it would be noticed of not receiving the messages from the event log. Here's another thread that contains a lot of debugging and logs that shows the DON/DOF and information. The point of this is not to compare which system is better, but to use two systems to show differences in behavior and trying to understand where that difference is and the cause. The current testing shows the messages are passing the test on the network as the HS controller has no problems and events run as they should. The ISY appears to be "missing" messages or simply ignoring them and not reacting.
paulbates Posted March 1, 2019 Posted March 1, 2019 I don't think USB vs serial PLM can make a difference in responsiveness from a design perspective. Insteon traffic is spec'd to burst at 14kbps and nominal ~2kbps. That's as fast as its coming in, it does matter how its connected to the controller. At 19.K, both PLMs are faster than the traffic that they support. Mark sandler's plugin can also connect through the insteon hub's rest interface. The only difference between those 2 is that rest polls the hub, its sort of like a serial/ip over rest. Messages from the insteon network to homeseer were slower on the hub, and in an unpredictable way as a message from the network may be sitting there for up to the polling frequency to get picked up and acted on. There's the conflict of more frequent polling bogs down the ET network and server with busy work. The hub is a bad solution (for me) if there are programs that are initiated by insteon devices and an immediate response is required. I'm on 5.0.13B of ISY. I used several versions of 4 and several of 5 since the beginning. I've not noticed response to programs being that slow that it was noticeable... its not as fast as a switch directly controlling a scene.. but nothing else really is. If I have a program that reads the PLM/Hub and responds, there's a little bit of a delay in either HS/ISY compared to insteon/insteon. I never performed a side by side compare of the delay. the reliability has been perfect... programs always work. Something to look at for the ISY missing some events: one thing that can happen on the ISY is many programs running and/or tight looped programs. You'll see this by looking at your programs tab with "Details" turned on. Is there a lot of flashing? That's a sign Related to the last point, here's a question: for speed difference between controllers, how "loaded up" was hs vs the ISY with other running programs and nodeservers? The comparison should be on 2 "bare" systems with only the same programs and plugins/nodeserver, that would be a fair comparison.
simplextech Posted March 1, 2019 Author Posted March 1, 2019 32 minutes ago, paulbates said: I don't think USB vs serial PLM can make a difference in responsiveness from a design perspective. Insteon traffic is spec'd to burst at 14kbps and nominal ~2kbps. That's as fast as its coming in, it does matter how its connected to the controller. At 19.K, both PLMs are faster than the traffic that they support. Mark sandler's plugin can also connect through the insteon hub's rest interface. The only difference between those 2 is that rest polls the hub, its sort of like a serial/ip over rest. Messages from the insteon network to homeseer were slower on the hub, and in an unpredictable way as a message from the network may be sitting there for up to the polling frequency to get picked up and acted on. There's the conflict of more frequent polling bogs down the ET network and server with busy work. The hub is a bad solution (for me) if there are programs that are initiated by insteon devices and an immediate response is required. I'm on 5.0.13B of ISY. I used several versions of 4 and several of 5 since the beginning. I've not noticed response to programs being that slow that it was noticeable... its not as fast as a switch directly controlling a scene.. but nothing else really is. If I have a program that reads the PLM/Hub and responds, there's a little bit of a delay in either HS/ISY compared to insteon/insteon. I never performed a side by side compare of the delay. the reliability has been perfect... programs always work. Something to look at for the ISY missing some events: one thing that can happen on the ISY is many programs running and/or tight looped programs. You'll see this by looking at your programs tab with "Details" turned on. Is there a lot of flashing? That's a sign Related to the last point, here's a question: for speed difference between controllers, how "loaded up" was hs vs the ISY with other running programs and nodeservers? The comparison should be on 2 "bare" systems with only the same programs and plugins/nodeserver, that would be a fair comparison. I agree I don't think there's a speed difference between the Serial and USB PLM. But I wanted to present the differences that two different PLM were used. Mark's plugin uses the REST to update HS devices for status but that doesn't have any correlation with the receipt of the DON/DOF of Insteon traffic. Side by side was done of a ISY bare/clean and initially and things were good so I expanded the number of devices to full load ~50 devices / mixed switches/dimmers/KPL/MS/MSII/plugs/etc. After having a "full" system I then started testing again and this issue was very visible and is a problem. After what has been now a couple weeks perhaps? Trying different program changes, log reviews etc I decided yesterday to do the HS testing. Start of test was a Clean system. Testing was perfect. Then I loaded the system with all devices. Results the same. I then added in all of my "programs" into HS3 as events. NO ISSUES. I've ran HS3 for a while within my own system and I've had nearly a thousand devices and over a dozen active plugins and I never have this type of slowness around an "event" not processing. Point is I'm not trying to compare the systems. I am pointing out there is a problem that should not exist. The HS testing shows the Insteon network is clean and working. Yes I have errors, not a "perfect" network but it works reliably as it should with HS. I currently can't say the same with ISY as too much was just "ignored" and programs simply did not run. This was done in a "real-world" scenario of my own home with my own events/programs. If the thought is the system was "too busy" then what are the documented limits for programs that should take a fraction of ms to process a motion sensor or door sensor to turn on a light. As for nodeservers I've tested with them running and without running and the results are the same. The nodeservers should not interfere with any processing in regards to Insteon traffic processing as that has priority over everything else (per UDI).
Recommended Posts
Archived
This topic is now archived and is closed to further replies.