wmcneil

Yes, I understand debug takes some time. I'll try out 3.1.3 when it becomes available.

OK, I know you have a lot going on right now. Thanks for looking into it when you get a chance.

Yep, good news is that the testing folks are doing will help get PG3 from alpha to beta, but debug takes some time.

This is my understanding as well, but, currently there is breakage in the Node server store and Elk Node server will not update to 3.1.3. (See also this post)

I see the Node server store is reporting 3.1.3 is available. For my existing 3.1.2 instance, I tried both a restart, as well as a stop followed by a start, and in both cases the version reported is still 3.1.2 (I tried refreshing the web browser to be sure that was not the issue.)

I deleted 2.0.1, and installed 2.0.2 . The Node server asked me to press the home button on the 980(hRoombaBsmnt), when I did so, it then asked me to press the home button on the i7+(hRoomba1stFloor), when I did so, it then asked me to press the home button on the 960(hRoomba2ndFloor), when I did so it then displayed a messager saying it was initializing connection to hRoombaBsmnt, and that message never went away. I have attached the log. Note the following error in the log file: 2022-03-08 09:02:14,793 Thread-1 udi_interface ERROR roomba:process_q: local variable 'json_data' referenced before assignment Traceback (most recent call last): File "/var/polyglot/pg3/ns/00:0d:b9:53:c6:f0_3/roomba.py", line 666, in process_q log_string, json_data = self.decode_payload(msg.topic,msg.payload) File "/var/polyglot/pg3/ns/00:0d:b9:53:c6:f0_3/roomba.py", line 1207, in decode_payload return formatted_data, dict(json_data) UnboundLocalError: local variable 'json_data' referenced before assignment Roomba_3-8-2022_90434_AM.zip

For others who may experience the "Zwave dongle not responding" with the Zooz zst10 700 USB stick: There is not quite enough space for the stick to be plugged directly into the polisy and maintain a consistent electrical connection. The USB stick is rubbing on the power connector(my polisy power adapter cam with a coax adapter that adds extra thickness where the power cord plugs into the polisy), and it seems to be held away from plugging fully in due to the edge of the RJ45 connector. The amount of mechanical interference seems small, but I am convinced it was causing random not responding problems due to the USB stick being on the edge of connecting/not connecting. I have purchased an angled USB adapter that others have recommended in another thread (here), and that seems to have solved the problem.

I have three roomba vacuums. A 980, a 960, and a i7+ . I have tried several iterations of deleting the PG3 Roomba Node server, and then installing it again. On every iteration, after the Node server starts up for the first time, it displays the message asking me to press the home button on the 980, and once I do so (and release it), it displays The "initializing connection ....", and then appears to install the 980 roomba correctly. On one of the iterations, I think it did ask me (on its own) to press the home button on the 960, but then after the 960 was added, never asked me about the i7+ . On most iterations, after the 980 is installed, it never asks me about the 960 or the i7+ . In this case, if I press the Discover button, it starts over again asking me to press the home button on the 980. So it seems the Node server is not aware of all of my roombas. I have attached the log file package from an iteration where the 980 appeared to be added successfully, and it never asked me about either of the other two Roombas. Roomba_3-7-2022_15413_PM.zip

I am running IoP 5.4.0 and PG3 3.0.43. I deleted my PG2 roomba Node server (which was working correctly), restarted PG3, and installed roomba Node server on PG3 in the same slot that it was previously installed on in PG2. I created the exact same key names and values (I have three roombas) as PG2. Upon starting the roomba Node server, I am getting the following errors in the log: 2022-03-07 09:37:18,418 MainThread udi_interface INFO polylogger:set_basic_config: set_basic_config: enable=True level=30 2022-03-07 09:37:21,039 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.0.36 Starting... 2022-03-07 09:37:21,368 MainThread udi_interface.interface INFO interface:__init__: Initialization received from Polyglot V3 3.0.43 [ISY: 5.4.0, Slot: 3] 2022-03-07 09:37:21,370 MainThread udi_interface.interface INFO interface:__init__: Connect: Network Interface: {'addr': '10.55.83.193', 'netmask': '255.255.255.0', 'broadcast': '10.55.83.255'} 2022-03-07 09:37:21,373 Interface udi_interface.interface INFO interface:_startMqtt: Connecting to MQTT... localhost:1888 2022-03-07 09:37:21,383 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-03-07 09:37:21,384 MainThread udi_interface ERROR udi_interface:write: File "./roomba-poly.py", line 885, in <module> 2022-03-07 09:37:21,389 MainThread udi_interface ERROR udi_interface:write: control = Controller(polyglot) 2022-03-07 09:37:21,390 MainThread udi_interface ERROR udi_interface:write: NameError 2022-03-07 09:37:21,391 MainThread udi_interface ERROR udi_interface:write: : 2022-03-07 09:37:21,391 MainThread udi_interface ERROR udi_interface:write: name 'Controller' is not defined

OK, thanks for logging the issue.

I have a PG3 elk Node server 3.1.2 running with IoP 5.4.0 . I am testing with the elk security controller set to disarmed. I have CO detectors tied into an Elk wireless zone that is elk definition 17=Carbon_Monoxide and Elk type 0=EOL_Hardwire_Wireless . When I test the CO sensor on that zone, the Elk security controller correctly detects the sensor is violated, and takes the actions defined for a CO alarm. The corresponding elk Node server zone does not show any change, it remains as shown in the attached picture. Also, the elk Node server area alarm status does not change to "Carbon Monoxide Alarm". elk_co_normal.pdf

I did have "Query at restart" checked. After unchecking it, the issue goes away. I am also surprised, given the higher performance hardware of Polisy, that the query operations are taking that long.

I have migrated from my 994 5.3.4 to IoP version 5.4.0 Everything is working as expected, except after an IoP reboot, a system busy window is popping up, and taking on the order of 10 minutes to complete. This is happening three times in a row, for a total of about 30 minutes of System Busy popups being present. This 30 minutes of time is happening even if I make no changes whatsoever to IoP, and only do a reboot. I have 4 zwave devices, 14 insteon devices, and 3 PG2 node servers (unchanged from 994 to IoP, except of course for pointing PG2 at IoP instead of 994). All of the devices and node servers seem to be behaving properly. Many of my programs are colored yellow, because the Elk nodeserver does yet support Elk thermostats. so I can't fix those programs yet.

Thanks, I realized the outputs key value in the elk nodeserver was empty. Once I put a range in there, they now appear.

Thanks, but I'm not seeing how to get an ISY program to respond to an Elk output changing. In a program, when I select a condition / status / area , the list of choices in the pulldown (Alarm Status, Armed Staus, ....) does not seem to include a choice for an Elk output?

@dbwarner5, thank you for this very detailed and helpful guide. One thing that I ran into that would be useful to add to your list is that the Elk nodeserver is currently missing multiple functionalities that the Elk module has. Three examples that are affecting me: the ability to respond to Elk keypad button presses, the ability to send text to keypads, and the ability to control Elk attached thermostats. There is a list of requested Elk nodeserver features here: https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/13

Replying to my own question, I see that thermostats does have an issue open (https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/50), and I also see that recognizing Elk keypad presses also has an issue open (https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/issues/69)

I am in the process of migrating from 994 to IoP, and it appears that neither the PG2 nor the PG3 Elk nodeservers support Elk thermostats. I just wanted to confirm that this is the case, because I do have Elk thermostats, and I do have quite a bit of program code for them.

I tried checking AC Configuration > Emails/Notifications > Settings/Groups : Use Default, and now SMTP is working. So "Use Default" was broken for a long time, now working again.

I upgraded to 5.3.4 . Now I am getting only the "Mail server failure [Password not accepted]" message (no longer getting "No network connection [[DHCP] state=RENEW]" mesage). I tired all of the following, same result for all: SMTP Server: smtp.googlemail.com SMTP Port: 587 "USE TLS" checked SMTP Server: smtp.googlemail.com SMTP Port: 465 "USE TLS" checked SMTP Server: smtp.gmail.com SMTP Port: 587 "USE TLS" checked SMTP Server: smtp.gmail.com SMTP Port: 465 "USE TLS" checked

I have been running ISY Firmware and UI version 5.3.0 at two different locations for many months. The google smtp server settings I have been using for a very long time are no longer working. I am getting the following message when I press the Test button in the AC Configuration > Emails/Notifications > Settings/Groups dialog: The ISY Network Settings (in AC Configuration > System) are set to "Automatic (DHCP)", and a valid local IP is assigned which I am using (without issue) to access the AC I am using these SMTP settings: SMTP Server: smtp.googlemail.com SMTP Port: 587 Use TLS checked

The first post in this thread applies. If you have a zwave card, you need to ensure it is the 500 series, else you should not update to 5.2.0

I have upgraded from 5.0.16c and 300 zwave module to 5.2.0 and 500 zwave module. Some items which will be helpful to anyone else making this transition: The directions for updating from 300 to 500 zwave module here state that you need to be running 5.0.13 or newer. I was forced to upgrade to 5.2.0 in order to get the zwave restore to work. This step failed when attempted with 5.0.16c, with "Dongle contains unsupported Z-Wave version and/or library" and "Failed to Restore Z-Wave dongle using backup..." messages present in the event viewer. After I upgraded to 5.2.0, and the zwave restore completed sucessfully, I was presented with the following window: I did not perform the zwave synchronize all. Most of my zwave devices (which are almost all gen5) were present and not showing errors in the admin console (AC). For those devices that were showing errors (exclamation point in front of the name in the AC), after I did a right click / zwave / show information in event viewer / all, the exclamation point went away, and the association and neighbors information in the viewer looked correct. The only possible remaining issue I have is that the device status under my Roomba and BlueIris node servers in the AC seem to be very sluggish about updating. I have rebooted both my ISY and my POLISY, and the sluggishness persists. Some of the status fields are updating, but not all of them. I'm going to give it some more time and see if it resolves on its own.

I was referring to the migration from 5.0.16C and 300 series zwave module to newest 5.x firmware and 500 series zwave module.

I'm a long time ISY user, have lots of gen5 devices and a few gen3 devices. Thank you to blueman2 and others that have reported their issues with moving to 5.2.0 . I still have the gen3 zwave module. I haven't upgraded to gen5, because I was waiting to see if polisy as a replacement platform for ISY would be a better place to move forward on zwave. It now looks like polisy replacing ISY could be quite a long way off in the future, and now we see that UD is moving to "500 module required" for firmware updates as part of getting zwave certification closed. Also, I see 500 modules are out of stock again currently. It seems likely to me, based on the experiences posted here, that 5.2.0 may require a lot of heavy lifting for users who haven't previously moved to the 500 module, and/or have gen3 zwave devices. So I'm waiting until the 500 modules are available again, and also to see if we get fixes or improvements beyond 5.2.0 that reduce the amount of heavy lifting.