ISY4Me

@Javi I am currently running all PG3 node servers and yes, I have updated to the new PG3 version as well as the latest updates for Polisy and ISY. In the course of attempting to see if the connection method made a difference (Portal vs Local), I have synced many times. I have also tried disabling the status update options in the UD Mobile options and that did not change the response. Perhaps @Jimbo.Automates can comment if there are any open issues on the node server.

I can’t determine if this is a UD Mobile issue or something specifically related to Ecobee thermostats. I have three Ecobee thermostats set up in UD Mobile and every time I tap on any one of the thermostats, I see the error message shown in the photo. I have searched for others seeing the same and I have not seen any related posts. I have also tried connecting locally and through the portal and the same error results. This only happens There has to be some setting that I over looked.

I ran multiple tests this morning and finally was able to get a persistent change. I think @Jimbo.Automatesis correct, in that something was not under control. So, this is the criteria that finally appears to work. I set the Ecobee app "Device Settings" for "Hold Duration" to the "Until I change it" selection In IoP, I programmatically set the Climate Type to my "Away" test comfort setting, but I had to set the "Hold Type" to "Indefinite Hold" to keep the changed value for climate. In IoP, programmatically issue a "Wait" command for two minutes to give time for the last command to propagate to the thermostat settings. Changing the Climate Type will change the Schedule Mode to "Hold Next", so that setting needs to be stable before forcing it in the next step. Perhaps it can be shorter that a 2 minute delay... needs further testing. In IoP, programmatically issue a "Schedule Mode" change to "Indefinite Hold" In the testing so far, the Temperature, Climate and Schedule Mode are all staying as set in the experiment. They did not change when the Ecobee when through a Scheduled Comfort Setting change. I then manually changed the schedule on the Ecobee App to go back to my standard daytime schedule and again, the Temperature, Climate and Schedule Mode remained the same as they were for the Away Test experiment. Reverting back to standard operation is as simple as issuing an IoP command to change "Schedule Mode" back to "Running" and everything goes back to the standard schedule. The standard Ecobee Vacation Mode is a very good tool, but I am optimistic that being able to programmatically control things will give me other options where they are needed.

@larryllix I agree with all of your comments. I have test driven the Ecobee Vacation mode and it does work well. This is an experiment to see if something equivalent can be done with programming control from IoP. I did run the 2nd IoP experiment I mentioned... setting the Set Climate to Away and then followed it immediately with Set Schedule Mode to Indefinite and even then at the normal 7:30 AM Climate/Comfort Setting schedule change over it still changed to the normal schedule and did not hold the experiment settings. That surprised me a little, I would have thought setting the schedule mode to indefinite would not change anything until the user intervened. My internal schedule hold duration is set to "Next Scheduled Activity", so that could indeed be overriding any programmatic setting. I can run those experiments. This is my first heating season with the Ecobee, so I am still learning the best way to control things. It is always fun having a little challenge and learning experience. Thank you for the feedback.

I am trying to implement a programmatic solution to emulate vacation mode. The test was fairly simple. In the first image you see the test command to change the Climate Type to "Away" with Hold Type "Hold Indefinite" When this test condition is forced to run, it implements the change as seen in the next photo. You can see that the Climate Type was changed to Away and the Comfort Settings for "Away" changes the Heat Setpoint to 52 degrees and that also is changed. But the Schedule Mode is set to Hold Next. So, I just ran this test just before my normal 11:00 PM Comfort Setting change and the "Hold Next" did just as expected and changed to the 11:00 PM Setting and it reset the Schedule Mode to "Running" and the Heat Setpoint was set to the temperature for the 11:00 PM Setting... it did not hold the setting change indefinitely. While I have not run the test case yet, I know I can manually change the Schedule Mode to "Hold Indefinite" by adding another command to programmatically change the Schedule Mode to "Hold Indefinite", but the subcommand in the Climate Type selection to change to "Indefinite Hold" is incorrectly changing the Schedule Mode to "Hold Next". I am assuming this is a PG3 NS issue. Please let me know.

Problem was fixed with IoP update... I believe it was 5.4.4 that resolved the issue and the fix has been confirmed.

@dex My system has undergone many changes since the original discussions, so these comments are coming from memory. I convinced myself that my PLM was flaky, but I had no definitive proof. So I replaced the capacitors on the PLM, factory reset when powering up for the first time and restoring the PLM when IoP was operational. To be safe, I took the approach of factory resetting all devices in my network before I powered up the rebuilt PLM for the first time... it was an attempt to try to start from an as clean a slate as possible. When updating for that first power up, I put all the battery devices in linking mode before the process started, but you can always disable that on the menu bar and manually update the battery devices after the power up. As you stated, the battery devices should be set in linking mode when the user queries the devices to get the original update... that is normal behavior. After all of this, I did see more "normal" battery device behavior. The Insteon motion sensors were exercised regularly... the Insteon Leak sensors did show updates in battery level when there was a significant change. Sadly, I didn't operate in that setup for very long, so I can't comment if it was a true solution. Shortly after that effort, I decided to convert all hardware to Z-Wave. Battery devices on z-wave still have some similar constraints... that was not the reason I moved to z-wave, but there are some always powered z-wave sensor hardware options and that has helped stabilize the motion and leak sensors in my setup.

I have been working with the command line options for querying the Bond Bridge in an attempt to understand the errors in the log file. Initially I was seeing a http 401 authentication error when the Discover command is issued. Then today, after deleting the Bond PG3 Node server, re-installing and setting up the configuration settings (hostname and token), I saw a http 404 error. I have been working with @Michel Kohanim to assure that any valuable information was forwarded to the developer and that process was in motion. As @DaveStLou had noted we were both seeing issues on v3.3.13 firmware. Communications with Bond Support did not raise any issues with the v3.3.13 firmware, but in the back of my mind I was always wondering. So this afternoon, I did factory reset the Bond Bridge. This was a recommendation of the Bond Bridge Support team and the process to rollback the firmware to what it was when it was manufactured is as follows... Do a backup of the Bond Bridge (click on Advanced in the Bridge on your phone app) Remove power from the bond unit Press and hold the reset switch located next to the USB cable connector Restore power to the bond unit while holding the reset switch Hold the reset switch until the ring flashes white (about 10 sec)... keep holding Light ring will turn solid red (5 LEDs) Release the reset switch Once the ring returns to flashing green, proceed with setup. The bond firmware will be updated automatically I was hoping that I would not have to reinstall the devices, but in my case doing a restore after the factory reset would not work. It kept complaining that I am not on the same WiFi network as my Bond Bridge, but I was. So, I re-added all the devices again in the Bond App. After the factory reset, I noticed that my WiFI configuration was still in the app and the token for the Bond Bridge had not changed. Note, after the factor reset, my unit did not return to a flashing green... it returned to a flashing blue state, which perhaps reflects why the WiFi and other settings were still intact... your results might be different. When I had a flashing green in the past I had to re-enter the WiFi setup. I did not try to reset a 2nd time to see if I could get a flashing green, I just proceeded as I just didn't give it a thought at the time. After the reset, my firmware had returned to v2.22.6. Yours might be different depending on when your unit was manufactured. Also please check your token changes. You will need to assure that data entry is correct in the Bond PG3 Node server Configuration settings After all was said and done, I went back to the Bond PG3 Node server (I did not do a Restart, although I feel I probably should have). Then power cycled the Bond Bridge to unlock and then performed a Discover. Watching the log file as I did this, there were no errors and the devices started loading. What is the interaction between the Bond PG3 Node server and the changes that were in the Bond Bridge v3.3.13 firmware? I have no idea and perhaps @Goose66can comment when he gets a chance to look at what is going on. At this point, all the nodes/devices are back in IoP. Now, I just need to assure the programs are all clean. I hope this works for everyone else that sees this same problem. If you can get back operational, be cautious about firmware updates.

I am seeing essentially the same error. I just loaded a new device in the bond app and tried to get the device node added to the node server. When I execute the Discover the result is only the Bridge Node is added and none of the fans are added. I tried deleting the Bond PG3 and re-installing and it did not change anything. The only thing different from when I did something similar about a month ago, is that the firmware was updated to v3.3.13 firmware via the Bond Bridge App. Suggestions?

Nothing seems to have changed after the firmware update... I tried reversing the fan with the Bond Mobile App and it refused to change direction. I also took a quick look around the Bond Mobile App and the previous section for state tracking is gone and I can not find any settings in the App Settings, Bridge Settings (in the app) or the Fan Settings (in the app) that related to tracking the state. Should I just blow this configuration away for this fan and re-install the fan within the app? The fan is not a "bond built-in" design, so I will have to try a different setup and see if I get a better response.

Thank you for your inputs. To answer your question, the fan does give me problems if I try correcting the direction from the Bond Mobile App. So, I will assume that there are issues with the Bond Bridge setup. The Bond Bridge is physically as close to the fan as possible... approx 11 feet straight below it. As far as interference, that is a more difficult thing to quantify. I have used the physical remote for the fan to try to get the direction corrected, so tracking corruption is also a possibility. There are a total of 4 fans in the house under control of the bridge and direction on the main fan is the only known issue I have. Looking at the device settings for the fan in question, I examined the advanced settings and the "Fix Tracked State" only shows a toggle for the light. A tracked state for the fan is not present. As far as "having tracking turned on". I have never set anything and in looking at the Bond Mobile App I can not see where that can be done. If there is a tracking history, can that data be examined? How? Continuing to look around the app, I see the current firmware on the Bridge is v2.28.0 and that v3.3.8 is available. So perhaps I need to start there and see what changes. I will continue feedback after I evaluate the firmware update.

I am controlling a Bond Bridge on IoP via Bond PG3. Getting everything setup went as it should and all the nodes for my four fans show in IoP. None of my fans were designed with Bond Built-In, so I went through multiple trials to assure that I had a good setup in Bond App before integrating into Polisy PG3. I am trying to manage the main fan in the living room with directional control based on temperatures. Overall, it does work. This main fan has both forward, reverse and N/A controls in the IoP Node, but probably 65% of the time when I tell it to change the direction it does not. I have added in code to tell the fan to stop, then change direction and then turn it on, but it is no more reliable. In contrast, if I go to the physical remote control for the same fan and I hit the reverse direction button (only a toggle on the remote), it always works 100% of the time. Are there other users that have similar experience?

Thank you, I will do that in the morning.

With the test of ISY994 Pro in control of the network (swapping out hardware and properly restarting), I could see the "Program Lock" disabled and the LED was enabled for both of the 2844-222 Motion Sensor II sensors. Under ISY994 Pro control I was able to toggle the LED check box and observe the updates being written to the Insteon 2844-222 Motion Sensor II. As I have no experience with the "Program Lock" I did not try to change its state (which was "off"). Essentially, the behavior under the control of the ISY994 was as expected and for the years that configuration was stable. I then switched the network back to IoP. Just to assure all was OK, I reset the PLM, Restored the PLM and Restored all devices. Then looking at the 2844-222 Motion Sensor II, the options were has they have been with the "Program Lock" ON and the LED OFF and the state of either of them could NOT be changed. Same PLM and Motion Sensor hardware for both tests. Are there users with IoP running 2844-222 Motion Sensor II sensors... can you check if you have the same issue with the "Program Lock" and LED being unchangeable?

Thank you for the suggestion. I did exactly what you describe many times and nothing changed. I normally work off DC Adapter, but I tried using the battery to run the 2844 Motion II Sensor as well. Factory resets didn’t affect the “Program Lock”… it was still enabled after the factory reset. LED state also continued to show disabled, even though it is actually showing a response to every motion detected.

Thank you for the “Program Lock” description. I just put my old isy994i back in service just to look at these Insteon 2844 Motion II Sensors in my old configuration. On the isy994i the 2844 Motion II Sensor do not have the lock enabled… this is only showing when I have the network being controlled by the IoP. Why would the IoP being showing something different for the same piece of hardware? …and not allow me to disable it?

If I try changing something like "timeout", then yes I see it writing the changes to the sensor. I just can't change the LED state or the "Program Lock" state (although do not know what the "Program Lock" state is) as mentioned in the last post.

I was watching the screens as I clicked OK in the communications warning (after putting the device in linking communications). If I was disabling (unchecking) the “program lock” it would recheck the box and exit the communications warning window. If I was trying to enable the LED it would uncheck the box and exit the communications warning window. In either of these two cases, there were no updates to the device.

I have two Insteon Motion Sensor II 2844-222 units I can not change the LED state. When I look at the options for either device, I see what is in the attachment. The odd thing is, it is reporting the LED as off, but when I see the motion sensor respond to movement, it always flashes the LED. If I check the box for the LED and go into communication mode on the sensor and hit OK in the communications warning window, the system un-checks the box and exits the communications warning screen and nothing changes and there is no writing activity to the device. The other thing I noticed is the top field in the options window for "program lock". I never set the "program lock" field, but I don't remember what it was when I was running on isy994 prior to IoP, but I never had these issues on the isy994. If I try changing the "program lock" field, I get the same response where after tapping OK in the communications warning window, it self-un-checks the box and exists the communications warning window and no changes are made. The role of the "program lock" and what it does if enabled, does not appear to be documented. I experimented with changing the timeout to see if other options were prohibited, but putting the device in communications mode, I can exercise a change and it shows in the options window after the update is finished. I have tried multiple hard factory resets on the 2844 motion sensor, but the same results are present. I also removed (deleted) the motion sensor and then added them back and the behavior did not change. Is the "Program Lock" preventing me from changing the LED state? If so, how can it be disabled? Suggestions?

At this point I am convinced that this is a PLM issue. I reset all devices in the network with the Polisy and PLM powered down. I then reset the PLM again and then powered up the Polisy and executed a Restore on IoP (battery updates disabled). The mistake I made was walking away when I did this, as when I returned I could not communicate with the newer Insteon Dual-Band devices, but could communicate with the old Insteon devices. Confused at all of this, I executed the Restore again (battery device updates disabled). This time I watched it and it would get to 6% and then abruptly stop and I still could not communicate with the Dual-Band Insteon devices. This behavior make me seriously question the PLM... so I commissioned the backup PLM, reset the backup PLM and re-powered the Polisy. This time I watched the Restore process and it proceeded past 6% and shortly thereafter I heard the ding on the first device is it was updating, then the 2nd and so on. This seemed normal and the restores I had been doing of the issues of the last three months where not like this. This time, after the restore process was completed, I did have the 1011 icon on the battery devices... which I did not see during the system restores of the last three months. I proceeded to write the updates to all the battery devices one by one. That process went as expected. At this point everything appears normal and I can communicate with all devices. Considering the observations during this process, I am expecting things to stay stable going forward, but only time will tell. I think it is time to rebuild the old 2413S and see if it can be put back into normal operation for future backups. Thank you for all the help.

Due to it’s age, I also have suspected the PLM. It is date coded 1329… I think it was put into service around 2014-2015. That is why I want to try swapping out with my backup (which I have not yet done). The backup PLM is date coded 1439, but it has been in storage since it’s purchase… probably around 2016. That original PLM was the same I used with the isy994. If it still had useful life, I wasn’t ready to retire it when the Polisy was commissioned. As far as resetting every device in the system… no, I have not done that, but I can try that next before switching to the backup PLM (trying not to change more than one thing at a time). Just note. The failure that I am experiencing does not have a defined trigger. So when I try something, I just have to make the change and then wait to see if the status stops updating. I will update this discussion when I see what happens with the original PLM and resetting all devices, which I will do this morning. In an attempt to define a trigger for the problem… I have experienced some power glitches since all this started, so I simulated a power glitch this morning (toggle the main breaker) to see if that was a trigger. When the system restarted, all the battery devices were reporting their status and they self updated the status with motion and leak test.

Two of the motion sensors are surrounded with dual band Insteon devices. The remaining motion sensor and the leak sensors are a little more isolated, but probably are within 25 feet. That being said, what I have seen is when one sensor has lost status updating, they all lose it. The motion sensors have been in use for 5-7 years and status updating issue never occurred before switching to IoP this year. I need to isolate if this is a PLM “end of life indicator” or IoP issue, which will require the PLM to be replaced with my spare unit. Then, it is just waiting to see if it is stable… I don’t know what triggers the status update failure, so I need to monitor closely. It could take a while to post feedback on this experiment.

Additional information I should have included in the original post… When I noticed that the status fields were not populating, I manually triggered each motion sensor and the status did not indicate any activity. I also manual tested the leak detector and the status field did not populate or indicate that it was wet. This completely empty status field that didn’t change with activity is what I observed in all three problem periods. i also went to each device and put them in the linking mode and initiated a query there as well and the status field remained unpopulated. The odd thing I observed this evening is that after Resetting and Restoring the PLM with battery updates disabled, there were no 1010 icons next to the motion or leak sensors… yet the sensors were responsive to activity and the status field updated with any trigger…. essentially all these sensors were working as expected. I will continue evaluating tomorrow and check daily to see if I can catch when this non-responsive status field returns.

Since I migrated to ISY on Polisy, I have had issues with Leak and Motion sensors stopping status updates. A query will update some of the attributes for the device, but not the status. This has happened three times since my isy994 to IoP conversion. During the process of evaluating the problem, I found that Restoring the PLM will allow normal status reporting to restart. My "fix" is to reset the PLM first and then start the normal Restore PLM procedure. In today's recovery, I disabled the updates to battery devices and the status reporting for them returned before I went around to write updates to them. What I don't know is why the status reporting stops... I will see some unexpected program response and when I go and look, the status field for the sensors are empty. In the three occurrences, all 3 motion sensors and 1 leak sensor all stop updating the status at the same time. My only thought is that it is a PLM issue, but why would it only be an issue with the status of the battery devices stopping their reporting? The PLM is quite old, probably 10 years, but this is the only unusual behavior that has been observed... all other PLM control over numerous Insteon devices has been normal. Any thoughts from the community? I do have a spare 2413S PLM, but if I swap them out I will not know for weeks whether or not that is a source of the problem. Also, I have been focusing on getting all programs stable on IoP, so I have not upgraded yet... still on 5.3.0.

Thank you, I think your additional information was what knowledge I was missing. i believe this will resolve my issue.