kzboray

Upgraded Polisy no issues, took about 3 minutes from start to finish.

@bgrubb1 Bitstring is updated to version 4.x in 5.5.4 OS update. This disables LifX from working as it requires version 3.1.9. If you install the 5.5.4 update it will remove the 3.1.9 version and install the 4.x version. The solution for both the eisy and Polisy are listed in the first post.

@stevesreed Don't worry about "Bad" It's been that way since the dawn of time or at least the first Polisy. It doesn't seem to effect operation.

@asbril Sorry mate. Keep us updated on the solution.

@Bumbershoot Great idea, but it won't work for this problem. The issue is one of the NS's dependencies is missing. More specifically the correct version is missing. The LifX NS hasn't been maintained and is becoming out of date in regards to the API and dependencies. The NS won't even start correctly unless you replace Bitstring 4.x with the expected 3.1.9 version. It shows up immediately upon starting the NS when you will see errors in the log file indicating it couldn't find the Bitstring dependency, and then when discovery tries to start, it won't be able to find any devices.

@asbril I've thought about your inability to get LifX working for the last few days and I'm not sure how to help you. I'm on a Polisy and you're using the eisy. The file structure is different between them so the original fix posted by xKing didn't work on the Polisy and I had to figure it out for the Polisy. The path for install on a Polisy is /var/polyglot/.local For the eisy you need to use: You will need to use putty or something similar to access the Polisy / eisy via SSH. You can log in with the user name <admin> and the password <admin>, then just copy and past the lines below one at a time and hit <enter> after each one. On the first command you will be promoted for password; use <admin> again. sudo -u polyglot bash pip3 uninstall bitstring pip3 uninstall --prefix /var/polyglot/pg3/ns/0021b9026038_7/.local bitstring pip3 install --prefix /var/polyglot/pg3/ns/0021b9026038_7/.local bitstring==3.1.9 Note that the /0021b9026038_7/ will need to be changed for your installation of the LifX NS. Look at your Polyglot dashboard and find the LifX NS slot number, then open putty and <cd> to /var/polyglot/pg3/ns. Then type <ls> you will see a list of NS by slot number, cut and past the correct NS name into the above command lines replacing /0021b9026038_7/ in both lines with your specific NS name. You should see something similar to this when you list <ls> the installed NS's. The number at the end of each name is the slot number. Be sure to use the correct one. [admin@polisy /var/polyglot/pg3/ns]$ ls 000db9560fac_1 000db9560fac_11 000db9560fac_3 000db9560fac_5 000db9560fac_7 000db9560fac_9 000db9560fac_10 000db9560fac_2 000db9560fac_4 000db9560fac_6 000db9560fac_8 You will need to restart Polyglot after you install Bitstrng 3.1.9. You should then see device discovery working. If not open a ticket with UD as the problem is not Bitstring.

@bpwwer ==================UPDATE============ I fixed it. but the question remains, will dev-packages install the correct Bitstring version for the LifX NS? Thank you again Bob, you rock and I so appreciate you and all your hard work! =====================Original Issue================================== I had to reboot my Polisy this morning and now my LifX is dead again. I applied the same fix I used last time. sudo -u polyglot bash pip3 uninstall bitstring pip3 install --prefix /var/polyglot/.local bitstring==3.1.9 But it's not working. I'm wondering if the Bitstring 3.1.9 is part of the dev-pacakages. It seems when I add it, it gets erased upon reboot which isn't a long term solution. And now I can't get it to work at all. Any suggestion would be appreciated! Thank you!

@someguy To the best of my knowledge there are two NS available that allow integration between UD products and alarm panels. Elk is one and the other is DSC. The Elk integration is handled by the very extensive Elk Polyglot NS that is actively maintained. The DSC integration is managed by the Envisalink-DSC NS which is also actively maintained. Elk is easier to program and offers extensive customization's that are not available with DSC, but most of those functions are duplicated and easier to manage on the ISY / Polysi / eisy anyway. For reliability I have to give a slight advantage to Elk, but they are both solid systems.

@Bob A @Jimbo.Automates This is how I do it in RP2. I haven't used the NS yet, but it may be able to do something similar.

@xKing =============Update============= Update 1/21/2023 The file structure for Polisy is slightly different than the eisy use the following to replace bitstring on a Polisy. sudo -u polyglot bash pip3 uninstall bitstring pip3 uninstall --prefix /var/polyglot/.local bitstring pip3 install --prefix /var/polyglot/.local bitstring==3.1.9 ===============Original Problem============ I've tried the suggested uninstall / install you listed above and am still have some issues. Can you point me in the right direction? This is on a Polisy running 5.5.4. 2023-01-20 14:05:58,036 MainThread udi_interface INFO polylogger:set_basic_config: set_basic_config: enable=True level=30 2023-01-20 14:06:00,769 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.0.46 Starting... 2023-01-20 14:06:00,835 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2023-01-20 14:06:00,836 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/000db9560fac_3/./lifx-poly.py", line 10, in <module> 2023-01-20 14:06:00,838 MainThread udi_interface ERROR udi_interface:write: import lifxlan 2023-01-20 14:06:00,839 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.9/site-packages/lifxlan/__init__.py", line 1, in <module> 2023-01-20 14:06:00,841 MainThread udi_interface ERROR udi_interface:write: from .lifxlan import LifxLAN 2023-01-20 14:06:00,841 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.9/site-packages/lifxlan/lifxlan.py", line 10, in <module> 2023-01-20 14:06:00,843 MainThread udi_interface ERROR udi_interface:write: from .device import DEFAULT_ATTEMPTS, DEFAULT_TIMEOUT, Device, UDP_BROADCAST_IP_ADDRS, UDP_BROADCAST_PORT 2023-01-20 14:06:00,844 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.9/site-packages/lifxlan/device.py", line 29, in <module> 2023-01-20 14:06:00,845 MainThread udi_interface ERROR udi_interface:write: from .msgtypes import Acknowledgement, GetGroup, GetHostFirmware, GetInfo, GetLabel, GetLocation, GetPower, GetVersion, \ 2023-01-20 14:06:00,846 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.9/site-packages/lifxlan/msgtypes.py", line 9, in <module> 2023-01-20 14:06:00,848 MainThread udi_interface ERROR udi_interface:write: import bitstring 2023-01-20 14:06:00,849 MainThread udi_interface ERROR udi_interface:write: ModuleNotFoundError 2023-01-20 14:06:00,849 MainThread udi_interface ERROR udi_interface:write: : 2023-01-20 14:06:00,850 MainThread udi_interface ERROR udi_interface:write: No module named 'bitstring' [polyglot@polisy ~]$ pip3 install --prefix /var/polyglot/pg3/ns/000db9560fac_3/.local bitstring==3.1.9 Collecting bitstring==3.1.9 Using cached bitstring-3.1.9-py3-none-any.whl (38 kB) Installing collected packages: bitstring Attempting uninstall: bitstring Found existing installation: bitstring 4.0.1 Uninstalling bitstring-4.0.1: Successfully uninstalled bitstring-4.0.1 Successfully installed bitstring-3.1.9 [polyglot@polisy ~]$

=============Update============= 1/21/2022 This has been resolved. Use the following to install the necessary bitstring dependency on Polisy sudo -u polyglot bash pip3 uninstall bitstring pip3 uninstall --prefix /var/polyglot/.local bitstring pip3 install --prefix /var/polyglot/.local bitstring==3.1.9 Use the following for the eisy sudo -u polyglot bash pip3 uninstall bitstring pip3 uninstall --prefix /var/polyglot/pg3/ns/0021b9026038_7/.local bitstring pip3 install --prefix /var/polyglot/pg3/ns/0021b9026038_7/.local bitstring==3.1.9 ================================================================================================ If you rely on the LifX NS you may want to hold off on updating to 5.5.4 until a fix is found for the NS's failure to discover devices after update. @xKing suggested patch: sudo -u polyglot bash pip3 uninstall bitstring pip3 install bitstring==3.1.9 Unfortunately this did not work on Polysi.

PG3 LifX NS no longer discovering devices. Restarted NS and PG3 several times. Also a power cycle of the Polisy. It seems something in 5.5.4 killed the LifX NS.

@bmercier O you didn't just say that. 🤣 If 25 years in IT operations taught my one thing it is, you never tempt fate! Thank you for all your hard work!

@C Martin This would be a good place to start. https://www.universal-devices.com/start/ Anything here talking about ISY programming which is most of it, applies equally to the Polisy and eisy. The ISY cookbook has a lot of examples in it, but don't ignor the other aids, they are very helpful as well. If you have a specific issue, feel free to ask here on the forum, people often chime in with example code.

Good Catch @Geddy! It is there, just very difficult to see.

@ddaggett1 I've also noticed over the years of working with Insteon and UD that the lights flicker when the admin console is writing to the system. I've never given it much thought as it has a cause and stops as soon as I'm done writing to the system. I caught my son making changes to the system that way once. He was trying to play a prank and I noticed the lights flicker and knew someone was in the system making changes. I'm curious if any of the more knowledgeable here have a more complete answer. Also I just checked the New Ticket button seems to be gone, it's a glitch in the matrix. I'd give it a few hours until the sun comes up on the west coast and try again.

@edwaud TPM is short for Trusted Platform Module. It is a cryptographic device (hardware) that is becoming more and more prevalent in all manner of tech. It makes hacking of a device so equipped, much more difficult. I just skipped over a lot of really important information and summarized in a not quit technically correct way, but that's the jist of it. It keeps your eisy safe.

@TRI0N https://www.universal-devices.com/docs/ZMatter-Assembly- Instructions.pdf

@3jtexas Auto DR should not be removed, nor do I believe it can be. AutoDR is Automatic Demand Response. Where supported, it allows the utility (power company) to send a message that the ISY would react to by turning off heavy loads during peak times. There is likely more to it but that is my understanding. The AutoDR scene I believe is where you would place the "Heavy Loads" that should be turned off on request.

Z-wave is the devil. As much as manufactures say they follow the standards, there really are only loosely defined ideas. Each manufacturer can define what each register does and how it works or doesn't with other devices. Manufactures of z-wave devices don't even have consistent specifications for their own products let alone interoperability with other manufactures. What UDI is trying to do is add some stability and consistency to a technology that has no standards. It's going to be bumpy, but if they can tame Insteon without documentation and reverse engineer the technology, I have hope in their efforts to do something similar with z-wave. Keep reporting issues and supplying logs. Michel and his band of dedicated miracle workers will get things sorted. It's just going to take a bit of time.

@greensha A little more information would help. You referenced the ISY 994 with a series 500 z-wave module, and also eisy, but you didn't mention the ZMatter USB dongle which adds z-wave support to the eisy. For z-wave support on the eisy you will need to make sure the ZMatter USB dongle is plugged in.

You said you were migrating form your ISY to IoP, this would require back end services from UD. Once the migration is completed you would not need UD back end services to be working for your local system to communicate with Google or Amazon.

If the login server is having issues, it may also be part of the Amazon / Google cloud link. You may want to hold off doing to much more until the back end infrastructure is back up and running.

Ya, the login page seems to be down.

At a guess I don't think the migration from the original ISY to IoP finished. Can you log into the portal and go the the original ISY then click on <Select Tools> then hover over <Maintenance> and click on <Migrate to> You should see this selection box. Enter the address for the new IoP and select what you want transferred.