wmcneil

Bob, thank you. After thoroughly cleaning the pads on all three of my roombas and bases, and making sure the batteries were all charged up without question, I have done some testing and I now have consistent connectivity and response to commands from the AC. Also, whether the roomba is started from the phone app, or the AC, the status in the AC seems now to be tracking correctly. The only thing I notice that is a limitation is that the end of the node name for my i7+ roomba is "basic roomba", whereas my 960 node name ends in "series 900 roomba", and my 980 node name ends in "Roomba 980". So the i7+ is not having all its features recognized, for instance in the AC it does not have a "action on full bin", or "passes" variable. The lack of these features is not causing me any problems at present, just something to be aware of.

Murphy's law is enforcing itself on me in a big way today. I finally figured out that one of my vacuums was not getting sufficient connectivity with the charge pads on the base to obtain a proper battery charge. After I thoroughly cleaned the pads, and put the roomba back on the base, the roomba phone app is now reporting "battery charging, too low to start" for that roomba. I will have to wait until the battery charges up to do more testing, but for that one roomba I was definitely getting strange and inconsistent results due to the contacts being dirty and the battery being low, including what I now realize was connectivity problems with the wifi network. (Strange thing is that the clean light was turning on, and the vacuum seemed to behave as if it was rebooting when I forced a reboot, but it finally occurred to me to try cleaning the contacts - they were a little dirty. )

I tried sending a start command from the AC today, and that did not work (it was working when I tried it last week). I tried restarting the roomba node server, and now it appears stuck at the "initializing connection" to one of the roombas. There are error messages such as this in the log: 2022-04-25 15:25:00,831 Thread-1 udi_interface ERROR roomba:async_connect: Connection Error: timed out 2022-04-25 15:25:01,837 Thread-1 udi_interface ERROR roomba:async_connect: Attempting retry Connection# 0 One thing that I noticed last week when the roomba node server did appear to be communicating with my i7+ is that it labeled its node as something like a "basic" roomba, which does not seem correct. This seems as broken as it was when I last tried to get the roombas working a year or more ago. Not complaining, just stating that with my three roombas (960, 980, i7+) it continues to not work for me. I am wondering if there is a fundamental problem with trying to control the roombas both from the AC and from the roomba phone app? - this is just brainstorming, not clear if this is an issue or not.

When a vacuum is started from the Roomba app on my phone (in this case it was a scheduled start), in the ISY AC, the reported values are not updating (Running shows "Off", State shows "Charging", etc.) even though in the PG3 roomba node server log file I see updates happening consistent with the fact that the roomba is cleaning. Even after 10 minutes had gone by, the AC still did not report any changes. I tried a Query, and that had no effect.

Today the vacuums all started up due to scheduled starts coming from the roomba server (not from the ISY). In the ISY AC, the reported values are not updating (Running shows "Off", State shows "Charging", etc.) even though in the PG3 roomba node server log file I see updates happening from all three vacuums consistent with the fact that they are all currently cleaning. In the AC, I tried a Query, and that had no effect.

I installed 2.0.3 (on PG3 3.0.59), and was prompted to press the home button on my three roombas in turn, after which a message displayed about initializing connection to each of the three roombas in turn. There are now three nodes defined in the Roomba node server, and they are present in the IoP AC (5.4.3) as well. The displayed values in the AC appear correct. I did some testing of the start, stop, and dock commands from the AC, and things seem to be working correctly.

@bpwwer , any update on Roomba? I see that there is a 2.0.6 version in the non-production PG3 store, would it help if I tried this? Note: The roomba github link in the PG3 Node server store is broken.

I figured out what the problem was. I had mistakenly specified the wrong value for hue_port (I had mistakenly set it to the same value as isy_port). Everything is working correctly now.

That fixed it, cameras are now present in the AC, thanks!

I'm posting this here in the PG2 BlueIris topic, because there is no BlueIris topic for PG3. I have installed Blue Iris under PG3 3.0.59. While the Blue Iris Node server is present in the AC, the cameras are not present. (I am running IoP 5.4.3) I am able to successfully change the blue iris profile, so I know the node server is communicating with the Blue Iris server. I've attached the log file package to this post. BlueIris_4-20-2022_94453_AM.zip

I have installed the Hue Emulator on PG3 3.0.59 . The spoken table is not filling in, and ISY Connected field in the AC of IoP is "False". Looking in the log file I see it is saying isy_host and isy_password is not defined, but they are in fact defined. I have attached the log file package to this post. HueEmulator_4-20-2022_90830_AM.zip

@JimboAutomates, I updated PG3 to 3.0.45 and elk Node server to 3.1.4, and the CO alarm notification is now working correctly. I see the violated zone showing that it was violated in the admin console, and the area Alarm Status showed "Carbon Monoxide Alarm". Thanks for the Node server update!

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.