asbril Posted January 24, 2023 Posted January 24, 2023 This error originated from a custom integration. Logger: homeassistant.config_entries Source: custom_components/isy994/__init__.py:117 Integration: Universal Devices ISY/IoX First occurred: 8:01:28 PM (2 occurrences) Last logged: 8:02:59 PM Error setting up entry Eisy (192.168.86.29) for isy994 Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/config_entries.py", line 382, in async_setup result = await component.async_setup_entry(hass, self) File "/config/custom_components/isy994/__init__.py", line 117, in async_setup_entry await isy.initialize( File "/usr/local/lib/python3.10/site-packages/pyisy/isy.py", line 128, in initialize await asyncio.gather(*isy_setup_tasks) File "/usr/local/lib/python3.10/site-packages/pyisy/variables/__init__.py", line 73, in update await self.check_if_variables_defined("integer", results[0], results[2]) File "/usr/local/lib/python3.10/site-packages/pyisy/variables/__init__.py", line 85, in check_if_variables_defined if not (def_list := def_dict["c_list"]["e"]): KeyError: 'c_list'
shbatm Posted January 24, 2023 Author Posted January 24, 2023 Looks like you don't have any integer variables defined on the eisy and it fails in another new way... Either disable variables under the Configure menu in Home Assistant or add an integer variable in the eisy and reload. Sent from my SM-S908U using Tapatalk
asbril Posted January 24, 2023 Posted January 24, 2023 (edited) 14 minutes ago, shbatm said: Looks like you don't have any integer variables defined on the eisy and it fails in another new way... Either disable variables under the Configure menu in Home Assistant or add an integer variable in the eisy and reload. Sent from my SM-S908U using Tapatalk You are right...... I now added an integer variable. I don't know whether it made any difference, but in fact I did a restore of backup I made yesterday and then did the upgrade of the HACS integration and that seems to have done the job. Thanks !!!!!! But I still seem to have the status-not-changing issue. Edited January 24, 2023 by asbril
asbril Posted January 24, 2023 Posted January 24, 2023 Most devices don't change status but some do Logger: pyisy.events.websocket Source: /usr/local/lib/python3.10/site-packages/pyisy/events/websocket.py:196 First occurred: 9:18:52 PM (1127 occurrences) Last logged: 9:24:09 PM Unexpected websocket error EventData.__init__() got an unexpected keyword argument 'fmt_name' Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/pyisy/events/websocket.py", line 171, in websocket self.router.parse_message(msg.data) File "/usr/local/lib/python3.10/site-packages/pyisy/events/router.py", line 148, in parse_message self.route_message(EventData(**event)) TypeError: EventData.__init__() got an unexpected keyword argument 'fmt_name'
shbatm Posted January 24, 2023 Author Posted January 24, 2023 Updated to 4.0.3 to fix the above 2 issues. 1
asbril Posted January 24, 2023 Posted January 24, 2023 1 hour ago, shbatm said: Updated to 4.0.3 to fix the above 2 issues. YESSSS.... I have not tested every device but so far so good. 1
MrBill Posted January 24, 2023 Posted January 24, 2023 16 hours ago, shbatm said: The warning is expected for now. I reactivated the old beta repository and it hasn't been removed from the removed list yet in HACS. I didn't realize it was a warning, the wording is a bit confusing: In the end what caused the problem was me allowing the custom_component to be removed. And I think I was wrong about why it was hosed.... After going back progressively deeper into backups and still having the system come up with unrecognized entities I discovered the error log contained: 2023-01-23 15:36:12.955 ERROR (MainThread) [homeassistant.setup] Setup failed for isy994: Unable to import component: cannot import name 'PROTO_GROUP' from 'pyisy.constants' (/usr/local/lib/python3.10/site-packages/pyisy/constants.py) This error persisted thru restorals of full backups, going back a day at time, when the newest should have been before installing the alpha custom_component. Tried to find the file /usr/local/lib/python3.10/site-packages/pyisy/constants.py to attempt manually editing (if I could figure out what should be there), but the path doesn't seem to exist: /usr/local/lib/ doesn't have python3.10 To resolve, I ended up with a fresh HA image and restored the latest full backup, and got everything back to normal. I don't know what or how PROTO_GROUP is or got hosed, but that seemed to be the issue. The corruption likely occured when the custom_component was removed.
shbatm Posted January 24, 2023 Author Posted January 24, 2023 (edited) 10 minutes ago, MrBill said: I don't know what or how PROTO_GROUP is or got hosed, but that seemed to be the issue. The corruption likely occured when the custom_component was removed. Most likely what happened between installs and removals is Home Assistant was trying to use the wrong version of PyISY. PROTO_GROUP is just a string for identifying if something is a Scene, but it changed in the alpha version. Edited January 24, 2023 by shbatm
shbatm Posted January 24, 2023 Author Posted January 24, 2023 Quote /usr/local/lib/python3.10/site-packages/pyisy/constants.py Also, make sure you're looking inside the Docker container file system
MrBill Posted January 24, 2023 Posted January 24, 2023 4 minutes ago, shbatm said: Most likely what happened between installs and removals is Home Assistant was trying to use the wrong version of PyISY. PROTO_GROUP is just a string for identifying if something is a Scene, but it changed in the alpha version. What was surprising is that PROTO_GROUP apparently lies outside the context of a full backup. (I use Sabeechen's google drive backup) To successfully restore I needed a HA new image, the same backup restoral without a new image left it hosed. 3 minutes ago, shbatm said: Also, make sure you're looking inside the Docker container file system I let supervisor manage the containers for HA and the add-ons, the above path is from logging in to the file system via root. the same / contains /config/ (I admit I don't completely understand file systems with respect to containers... I learned users, groups and permissions in a very different linux era)
shbatm Posted January 24, 2023 Author Posted January 24, 2023 1 hour ago, MrBill said: What was surprising is that PROTO_GROUP apparently lies outside the context of a full backup. The "full backup" in Home Assistant's case is just a backup of your config directory and the database. So unless you're doing a full image like on a VM, the python modules are downloaded and reinstalled each time. Testing the way this does adds to the possibility for a f*up because both the "PyISY" and "PyISY-beta" packages provide the `pyisy` module (the latter is supposed to override the former). As for the file system--/config is just mounted from the server into the docker container, which has it's own "overlayfs" file system. tl;dr: if you want/need to muck about with the actual Docker file system, use "docker exec -it homeassistant bash" (e.g. run a bash shell inside the homeassistant container)
asbril Posted January 26, 2023 Posted January 26, 2023 (edited) I noticed that HA was upgraded to 2023.2.0b0 and globally the ISY Integration works fine. However I noticed that cards with a single entity no longer change to yellow (with intensity depending on %). However in a card with multiple entities where these entities appear as either ON or OFF, ON is shown in yellow. Unless mistaken, the color intensity went yellow as well in single entity cards. Edited January 26, 2023 by asbril
Mecheng70 Posted January 30, 2023 Posted January 30, 2023 (edited) Has anyone used the number.set_value? Have been playing with this today and noticed that it is throwing an error saying that it isn't successful but it does update on the eISY. Really cool that it updates both the variable and the init in the same command. However, HA reports an error: Logger: homeassistant.components.websocket_api.http.connection Source: components/websocket_api/connection.py:150 Integration: Home Assistant WebSocket API (documentation, issues) First occurred: 9:57:41 AM (16 occurrences) Last logged: 11:10:04 AM [140067744811040] Error handling message: Could not set s.casita_guest_code Initial Value to 4444.0 for 1.33 (unknown_error) from 172.16.5.71 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36) [140067744811040] Error handling message: Could not set s.casita_guest_code Initial Value to 7847.0 for 1.33 (unknown_error) from 172.16.5.71 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36) [140067744811040] Error handling message: Could not set s.casita_guest_code Initial Value to 78471111.0 for 1.33 (unknown_error) from 172.16.5.71 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36) [140067744811040] Error handling message: Could not set s.casita_guest_code to 78471111.0 for 1.33 (unknown_error) from 172.16.5.71 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36) [140067744811040] Error handling message: Could not set s.casita_guest_code to 7847.0 for 1.33 (unknown_error) from 172.16.5.71 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36) can confirm that it is updating. Logger: homeassistant.helpers.script.websocket_api_script Source: helpers/script.py:409 First occurred: 11:02:41 AM (15 occurrences) Last logged: 11:10:04 AM websocket_api script: Error executing script. Error for call_service at pos 1: Could not set s.casita_guest_code Initial Value to 4444.0 for 1.33 websocket_api script: Error executing script. Error for call_service at pos 1: Could not set s.casita_guest_code Initial Value to 7847.0 for 1.33 websocket_api script: Error executing script. Error for call_service at pos 1: Could not set s.casita_guest_code Initial Value to 78471111.0 for 1.33 websocket_api script: Error executing script. Error for call_service at pos 1: Could not set s.casita_guest_code to 78471111.0 for 1.33 websocket_api script: Error executing script. Error for call_service at pos 1: Could not set s.casita_guest_code to 7847.0 for 1.33 Edited January 30, 2023 by Mecheng70
shbatm Posted January 30, 2023 Author Posted January 30, 2023 4 hours ago, Mecheng70 said: Have been playing with this today and noticed that it is throwing an error saying that it isn't successful but it does update on the eISY. Fixed here for Home Assistant core 2023.2.0b7: https://github.com/automicus/PyISY/pull/379 https://github.com/home-assistant/core/pull/86981 Not an issue in the HACS/PyISY4-alpha version--this was already corrected.
Mecheng70 Posted January 31, 2023 Posted January 31, 2023 1 hour ago, shbatm said: Fixed here for Home Assistant core 2023.2.0b7: https://github.com/automicus/PyISY/pull/379 https://github.com/home-assistant/core/pull/86981 Not an issue in the HACS/PyISY4-alpha version--this was already corrected. I have 2023.2.0b6 waiting to install.
gzahar Posted February 3, 2023 Posted February 3, 2023 On 1/22/2023 at 2:27 PM, shbatm said: For the most part, functionality is the same as what will be in Home Assistant 2023.2.0, but the engine running it has not been as thoroughly tested as the existing version. Since installing the HACS ISY integration, I have been installing HA updates as available. Most recently 2023.2.1 Is this overwriting the HACS install? Should I avoid HA updates for now or reinstall the HACS component afterwards?
shbatm Posted February 3, 2023 Author Posted February 3, 2023 It should not be overwriting it. You should be getting a warning in the log each time you restart that you are using a custom component (not tested by Home Assistant Yada Yada). The features in Home Assistant should be the same right now, just tweaks behind the scenes. If you start getting any errors in the log complaining about 'could not import x from pyisy' then try a reinstall from HACS (occasionally pyisy and pyisy-beta will mess up which gets priority) 1
shbatm Posted February 9, 2023 Author Posted February 9, 2023 @Mecheng70 Continued from Here... So I reloaded again this morning and what I thought were missing last night looks like it was a fluke on something else I changed--everything I expected was back. One breaking change (on the alpha version only) that I need to capture in the release notes though: anything that was categorized as a sensor, but was really an "On/Off" or "True/False" entity, now correctly gets sorted as a binary_sensor--so some entities may have changed. Also, 4.0.4 includes the first pass that will correctly get the node server information, so anything that would show up before as "GV1 = 0" will not report correctly (e.g. "Node Server Online" = "On"). @Mecheng70 - please let me know if the devices that aren't showing up are just sensors that switched to binary_sensor, or if there's more that aren't appearing. 1
shbatm Posted February 9, 2023 Author Posted February 9, 2023 https://github.com/shbatm/hacs-isy994/releases/tag/v4.0.4
Mecheng70 Posted February 9, 2023 Posted February 9, 2023 @shbatm Redownloaded the integration from HACS. Restarted HA. Still having the unavailable issue on most of them. Is there another version I should be looking for? 4.0.4 is what I downloaded. As for the sensors - most are showing up as unavailable under the Device Info screen. Lights/Switches - What is more interesting is that most of the child nodes are showing up as Unavailable versus Unknown.
shbatm Posted February 9, 2023 Author Posted February 9, 2023 It looks like there's an issue with the python module versions competing with the same namespace. I'm working on renaming things and will post an update later today. 2
asbril Posted February 10, 2023 Posted February 10, 2023 3 hours ago, shbatm said: It looks like there's an issue with the python module versions competing with the same namespace. I'm working on renaming things and will post an update later today. Everything seems to work on my HA.
shbatm Posted February 10, 2023 Author Posted February 10, 2023 Well, it's going to be a while now... Tried to reboot and hit Update Packages without thinking and now I have no ISY...
Mecheng70 Posted February 10, 2023 Posted February 10, 2023 4 minutes ago, shbatm said: Well, it's going to be a while now... Tried to reboot and hit Update Packages without thinking and now I have no ISY... I feel your pain. Good luck.
Recommended Posts