ISY4Me

@bpwwer I have looked at the /var/log/messages and attached the output starting with the last PG3 3.1.16 run. On 3.1.16 I did not look to see if the ISY was loaded, but the log file is different than the subsequent starts of PG3x 3.1.17 where it is complaining that IoX Service is not loaded and it fails to get the platform UUID. Output of "pkg info PG3x" is also attached. This EISY has seen very little activity... I received the EISY, Updated to 5.5.2, Restored Polisy ISY backup and did z-wave migrate, but this issue with PG3x was discovered after the restore of the Polisy ISY file. During this issue I have rebooted and restarted a number of times and it had no impact. PG3x Log File Output messages.txt PG3x Package Info.txt

Yes, I have both logged out and restarted PG3x on the EISY a few times. The EISY has been power cycled a few times. I have noticed a comment in The Portal… “Access Denied. Pending approval by owner”. I have not requested the Portal License be transferred yet nor have I requested a trial for the EISY. I was waiting to see how the Polisy -> EISY migration goes.

Thank you @bpwwer... IoX was restored and I started to look at PG3x restore process. Access to PG3x is not a problem, but it will not contact the server (I assume because I have not activated a Portal access yet). Does the ISY have to be added to configuration for the PG3 restore to work properly? I can't manually add the ISY (it fails with localhost or IP with Port 8080)... and it is not automatically detected... is this related to not yet having the Portal access active? Do these both have to be resolved before I start the PG3 restore process?

@bpwwer My work with the EISY is in progress and from the “out of the box” state, all the packages have been updated, included PG3x. The IoX Launcher is running fine and both my Polisy and EISY ACs are visible and accessible. In thinking about this process of moving to the EISY. I was wondering if the PG3 to PG3x NS migration should be done first or after basic ISY restore and z-wave migration ?

@Jimbo.Automates I saw that @bpwweris working on the issues with PG3x and is hoping for an update in the near future. My ecobee NS is one of the key components of my Polisy and will continue to be so on EISY. With all of the recent activity, I am leaving my Polisy system alone and it runs as my main system. Are there any cautions or guidance you can offer in advance about running Ecobee NS on PG3x?

I received a reply from @Michel Kohanim this afternoon regarding my ticket on this issue. Here is a cut/paste of his response... shared with his permission. There were no suggestions as to how to snap the excess off the board, but at least we are aware of the guideline. Michel Kohanim wrote: 2023/01/01 17:28 Hi Jim, Yes, so very sorry. You need to snap it in the middle. JWeaver01 wrote 2022/12/31 08:05:27 With no guidelines or instructions included with the Enclusure I was trying to mount the “as shipped” ZMatter board into the Enclusure intact getting interference with the posts of the antenna connector. Yes, there was extra depth to the cable that I originally pointed out, which made that interaction worst, but that may be a non-issue. But after looking closer at things this morning and seeing that one image of a mounted board (see attached) I am beginning to think that the full ZMatter board was never designed to mount in the Enclosure. Is snapping (or cutting) off the top half of the ZMatter board the sanctioned method approved by UD? Recommendations on how to do that without damaging the board?

While the old photo shows how the half board cleanly fits in the Enclosure, I am really surprised this was or has not been discussed by the UD Team. Just for clarity to the members reading this, I am not advocating such a physical modification until directed by the UD Team and seeing that this is a holiday weekend we may not see any real guidance until next week. If I get some feedback from UD I will post it… until then I am waiting.

It took me some 30 minutes to get the board in the enclosure as you are right that is not easy to fit it. The board is slightly tilted and one of the antenna pins kept coming off the board. Finally I did get the board (slightly tilted) in the enclosure and hopefully the antenna pin remains in place. I don't remember whether the problem pin is the Zwave or the Zigbee, but my eisy now does recognize Zwave. In other words, I'll have to wait for the Zigbee firmware upgrade to confirm that both pins remain in place. @asbrilFrom your comment it sounds like you did not remove the top half of the ZMatter board as was shown in the photo I added, as I had the same issue with the board being tilted any not completely seated… by not completely seated, I mean I could not use the supplied screws to “attach” the ZMatter board to the existing board in the enclosure (the screws were not long enough). It was tilted enough I was concerned about contact to the lid on the Enclosure and that left me uncomfortable. If removing the top of the ZMatter board is the recommended method (as shown in the photo) I can’t find it documented anywhere. I have submitted the question to the UD experts on a ticket to get an official answer.

I received my ZMatter Enclosure yesterday. In looking at the separately purchased ZMatter board there is no way to mount the full board as originally shipped into the enclosure without interference with the internal antenna posts, which keeps the board from seating properly. I ran across one old forum photo of the enclosure. It clearly shows that to eliminate that issue, the top half of the ZMatter board was removed or snapped off. Not finding any guidelines for this procedure (no instructions included with the Enclosure), I wanted to ask the community if snapping off the top half of the ZMatter board is the correct procedure? I don’t want to do anything that will impact my board warranty.

I will be taking a slow approach to moving to EISY. My base configuration is Polisy, Node Servers and Z-Wave running on 5.4.3 I want to start the configuration and migration to EISY in parallel until everything is stable. The EISY will have a different IP running on 5.5.2 (or later) and will only be powered up when the Polisy is powered down. My work with the EISY will start in a few days and I was wondering if we can have both Polisy and EISY configured in UD Mobile at the same time?

@bpwwer Is it safe to assume that these recommendations of moving PG3 all apply if moving from Polisy to a fresh installation in EISY?

@tmorse305Thank you for the example. I had just started something similar and as I use more node servers this definitely sounds like a great addition. Much appreciated.

I did look at the NS Log, but nothing seemed to align with the timing. I restarted PG3 twice and in the end restarted the Ecobee NS and all of that activity was noted, but prior to that should have been some indication of the problem and it was fairly clean... @tmorse305You mentioned you get a notification when it drops. Is that a program you have running or something else?

Without any indication as to why, all three Ecobee Thermostats IoP Nodes starting populating with data. There was nothing that was changed in my setup... data just appeared in the IoP Nodes and programs started working again. Just wandering if @Jimbo.Automates can offer any suggestions as to what might have happened?

Out of the blue today, I noticed the Ecobee NS is not reporting data to the IoP interface. I have checked the Ecobee Thermostat data on the Ecobee website and everything is current and updating. Node panels in IoP are simple all empty. I have restarted IoP and I have restarted PG3 and there is no change.

@Bumbershoot Thank you for the suggestion. I had not really thought about WiFi... after I decided to move away from Insteon (where I did use the Venstar 1700/1800), I moved to z-wave for control and Ecobee for the thermostat. With the new Polisy Add-In card coming for Z-Wave/Zigbee/Matter there may be other options possible, but I currently know nothing about Zigbee or Matter. My WiFi network is very strong, so with my desire to have instant communications between the thermostats and IoP, that might be an interesting approach. I will read through the link to the manual... thanks.

In the last few days I have started to experiment with a Honeywell TH6320ZW2003 T6 Pro Series Z-Wave Thermostat. My house runs on heat pumps, so to prevent the auxiliary heat from running, I have programs that run based on the outside temperature and the programs always keep the heat set point within 2 degrees of the actual temperature to prevent my electric bill from climbing when the temperature is above a level that will actually result in heating the house. I had been using Ecobee 3 thermostats to do this since I migrated away from Insteon and they are doing a good job, but there are times that the lag due to the cloud based communication via the Node server causes issues. So, I looked for a local control z-wave option and the T-6 looked like a reasonable model to try. I modified my old Insteon programs to re-align with the available settings on the Honeywell T-6, but I am seeing inconsistencies in the temperature value on the T-6 thermostat and the z-wave node panel within IoP (Polisy Pro with Zeus 700 USB). In addition, I am seeing long delays in the update of the temperature on the thermostat (sometimes jumping 2 degrees from the last reading) and there are long delays on the updates within IoP even after the T-6 display has updated with a new temp. I have the z-wave setup option set to update every 0.5 degree change, but the delays described still are present. Have other users seen the same or is this a design issue with the T-6? The inconsistent slow/delayed updating of the temperature on the T-6 and even slower reporting to the z-wave panel in IoP are the largest concerns. These make the lag of the Ecobee 3s a smaller issue in comparison. Are there recommendations for a local solution where the thermostat and the IoP communicate in real time and accurately?

@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.