ISY994 Variables as Sensors

[Blueman2]

Uh, that fact that pycache never came back should have been my clue. You nailed it. I was doing Hassio Restart, but I guess I needed to do full reboot. On reboot, it is now reading variables. It is hitting another error now on ‘binary_sensor:’ section, but I will see what I did wrong.

Live and learn…

edit: so is it ‘binary_sensor:’ as listed in the example above, or binary_sensors? The .py code seems to imply binary_sensors. Just checking.

edit:edit: yes, it is ‘binary_sensors’, all plural like you mentioned above. All errors are now gone. Re-adding the variables back into my custom UI. happy, happy!

edit:edit:edit: I noticed this is forked off of the code that did not have the update for Thermostats. Guessing that gets merged back in down the road.

[shbatm]

@Blueman2

edit:edit: yes, it is ‘binary_sensors’, all plural like you mentioned above.

Corrected in the original post. Thanks.

@Blueman2

edit:edit:edit: I noticed this is forked off of the code that did not have the update for Thermostats. Guessing that gets merged back in down the road.

Sorry for any confusion, I’m juggling a few different branches as I work through my PRs.

1. isy994-variable-sensors is linked above, and only includes the changes discussed here.
2. isy994-climate only includes the climate platform changes as currently approved by the Home Assistant team. PR is on hold pending PyISY updates and restructuring the full Hass Climate platform.
3. rest-json-attributes includes an update to the REST sensors to allow MQTT-sensor-style JSON attribute templates.
4. isy994-climate-dev includes all 3 sets of changes and is what I’m using as my custom-components

EDIT: 18-Jul-19 All changes are now tracked in one branch, the isy994-climate branch.

[Blueman2]

All is good in the world! Using isy994-climate-dev and I have all the variables working great with thermostat and most z-wave sensors being seen as sensors. I love being able to set the UOM, device class, and off/on value for variables. This is a huge step forward for ISY/HA integration.

I really appreciate your work on this. Just amazing.

[Blueman2]

Loaded your most recent updates from climate-dev. All still working fine.

[danbutter]

@shbatm

Yeah, this was a side effect of troubleshooting the z-wave thermostats. ISY reports all Z-Wave devices as the same “type” and its difficult trying to get the Hass implementation to correctly sort through them without having a Z-wave enabled ISY and being able to grab the /rest/node definitions.

Would it help to give you the /rest/node definitions of mine?
I have a zwave thermostats, locks, plugins, an outlet, light switches, floodlight, outdoor modules all on my ISY.

[shbatm]

Yes! Now that I have a decent understanding of the integration I’ll double-check & include what I can when I have time. You can upload them to a pastebin or GitHub Gist and send me a message with the link. Let me know if there is anything specific that you know isn’t working–I know one is the Multisensors.

EDIT: Actually I think I got what I need from Blueman2 and the ISY SDK. What I really need is someone to test the changes discussed in the link below. I can get halfway there by dumping @blueman2’s file into the ISY emulator, but Z-Wave doesn’t include state values until the event stream-- tl;dr: it has to be tested with real data I don’t have.

ISY994 Z-Wave Sensor Enhancements: Testers Wanted

After a few people have asked about Z-Wave issues in conjunction with my other improvements to the ISY994 integration, I took a stab at expanding out the Z-Wave categorization as well. Instead of trying to rely on ISY Device Types which don’t work for Z-Wave, I added a patch to the PyISY module to pull in the devtype.cat field from the ISY Node REST data. This, coupled with the ISY SDK allows all Z-Wave devices to be categorized just like Insteon with the Type field. In addition, this branch …

[shbatm]

Updates for anyone using this code:

ISY994 Z-Wave Sensor Enhancements: Testers Wanted

NOTICE TO ALL ISY USERS USING THIS CODE – USE THE isy994-climate BRANCH FROM NOW ON. All changes have been merged into one branch (including Z-Wave Updates, Variables, and Climate). I will stop pushing updates to the other branches. All changes have been combined for the PR to Home Assistant (you can follow along/comment here: https://github.com/home-assistant/home-assistant/pull/20970)

[Blueman2]

@shbatm,

I have been very successfully running your HACS ISY994 plug in. Thanks again for the great work on this. I was hoping you might help me diagnose an error message I get quite frequently. It happens when I query one of my z-wave devices using a REST command in order to ensure I have the most recent data (it is my home energy monitor). Here is the error I get:

2019-08-25 12:41:47 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/rest_command/__init__.py", line 103, in async_service_handler
    headers=headers,
  File "/usr/local/lib/python3.7/site-packages/aiohttp/client.py", line 497, in _request
    await resp.start(conn)
  File "/usr/local/lib/python3.7/site-packages/aiohttp/client_reqrep.py", line 844, in start
    message, payload = await self._protocol.read()  # type: ignore  # noqa
  File "/usr/local/lib/python3.7/site-packages/aiohttp/streams.py", line 588, in read
    await self._waiter
concurrent.futures._base.CancelledError

And here is the REST command I have set up in configuration.yaml:

rest_command:
  zw030_query:
    url: http://192.168.1.145/rest/query/ZW030_143
    username: xxxx
    password: xxxx
    timeout: 15

I added the timeout to see if that helps, but no joy. Any other thoughts? The command works fine to update my energy usage, but I one of those who hates seeing error messages in logs!

[shbatm]

You’ve got me on that one… it looks like it might be something core to the REST component and async libraries in use: https://github.com/aio-libs/aiohttp/issues/2098

[taylorsilva]

Hey @shbatm, I’m very interested in your work here! Any plans to to submit your work as a PR?

[shbatm]

Yes*.

These variable changes are part of several improvements to the ISY integration in Hass but also rely on some significant updates to the underlying PyISY module. Those changes are being reviewed and tested first before I start to trickle in the updates to Hass.

I highly recommend trying the ISY994 HACS add-in to help test these changes now and root out any bugs. The HACS add-in adds a drop in replacement for the default isy994 integration as a custom_component, but includes all of the updates.

[lovemyram4x4]

I just tried this out and found that it doesn’t seem to include decimal from my variable so my sensors reads 512 instead of 51.2.

I can make a template senors to correct this, but it would be nice if it showed it correctly in the first place.

[shbatm]

Sounds like the precision isn’t being picked up the way it should be. I’ll take a look when I get a chance.

[shbatm]

@Blueman2 - Do you (or anyone else using ISY variables in Home Assistant) use anything but the sensor platform?

I need to make a change to how these are configured to improve compatibility with the config flow.

The plan is to make variables behave similarly to the sensor_string and ignore options:

• The config will have an option for Sensor Variables String: "ha." Any variable names containing this string will be added to Home Assistant as as sensor.
• switch and binary_sensor will be removed, since those can be modeled using Programs already.
• Device class, icons and unit of measurement will be set in the device customization within Home Assistant, rather than the config.yaml.

Any objections to this?

[Blueman2]

I do make use of binary_sensor in my setup for 6 variables, but let me look at why.

[shbatm]

OK. The new v1.4 versions will have gotten rid of the binary_sensors. You’ll have to update your config to keep using regular sensors.

For the binary sensors: I would recommend setting them up as programs with the status returning true or false (see this page for the details).

I’m sorry, I hate removing functionality, but I’m in a big push right now to make this compatible with the core code and the way I set up the variables before is not going to pass muster when it gets to review.

[shbatm]

Also, just FYI - the new v1.4.x versions also have services to set variables from Home Assistant, so you’ll be able to update whatever variables you need to from within HA with the isy994.set_variable service.

[Blueman2]

WHAT? ) So I can change the value of a variable when that comes out? Very cool! I have been creating custom scripts to send REST commands to set variables.

WRT to the binary_sensor, no worries. I can easily work around that. I am very excited to see your work get put back into the core ISY function. That should make overall support going forward much cleaner. Well done, @shbatm!

[shbatm]

ISY994 HACS Version with PyISY-Beta

New Beta Version Released! (make sure “Show Beta” is enabled in HACS to be able to install this version) [1.4.2] - Services, Variables Reavamped, Inheritance Fixes MAJOR MILESTONE : Good-bye beta! Now running on pyisy==2.0.0 ! This is a major milestone towards enabling these changes to be migrated into the Home Assistant Core code, and have been over a year in the making! BREAKING CHANGES!! - Variable Support Has Changed in this Version! To ensure future support and ability to merge the ch…

Variables, Programs, and Network Resources can now be updated/run through Home Assistant services instead of separate REST commands.

[shbatm]

Should also mention, there is now an isy994.reload service which will let you pick up changes made on the ISY without restarting Home Assistant.