Jump to content

Home Assistant PyISY 4 Alpha Testing

shbatm

By shbatm
in Home Assistant

Recommended Posts

asbril Advanced

asbril

Posted
Posted

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'
 

Link to comment
asbril Advanced

asbril

Posted
Posted (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 by asbril
Link to comment
asbril Advanced

asbril

Posted
Posted

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'
 

Link to comment
MrBill Advanced

MrBill

Posted
Posted
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:image.png.e14f67b01d9b35cbd44f22a7ff67f4

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

image.png.48434d2b3ef44dfed747872ce6f64ee1.png

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.

Link to comment
shbatm Advanced

shbatm

Posted
  • Author
Posted (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 by shbatm
Link to comment
MrBill Advanced

MrBill

Posted
Posted
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)

Link to comment
shbatm Advanced

shbatm

Posted
  • Author
Posted
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)

 

Link to comment
asbril Advanced

asbril

Posted
Posted (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.

image.thumb.png.04fd8318dce48f538ef2876150773073.png

Edited by asbril
Link to comment
Mecheng70 Advanced

Mecheng70

Posted
Posted (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 by Mecheng70
Link to comment
gzahar Advanced

gzahar

Posted
Posted
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?

Link to comment
shbatm Advanced

shbatm

Posted
  • Author
Posted

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)

  • Like 1
Link to comment
shbatm Advanced

shbatm

Posted
  • Author
Posted

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

  • Like 1
Link to comment
Mecheng70 Advanced

Mecheng70

Posted
Posted

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

Link to comment
Guest
This topic is now closed to further replies.
Go to topic listing

  • Recently Browsing

    • No registered users viewing this page.

  • Who's Online (See full list)

  • Forum Statistics

    • Total Topics
      36.9k
    • Total Posts
      370.2k
×
×
  • Create New...