I left the config as it was. Note that switches, etc worked. Just not variables. My guess in pilot error on my part, but I did not spend a lot of time diagnosing it. I just reverted back to earlier version.
Let me try once again to see if I have any better luck.
I just did a re-upgrade to 1.2.0. It looks like the variables are there in Integrations. They are all listed under “Entities without devices”. But when I look at my Lovelace interface, the values all show up as “unavailable”.
OK, I think I see what is going on. My variables are all renamed with “_2” at the end. That is why my interface does not see them. It must think they are from a 2nd ISY?
Gotcha. A couple of things changed with this update that affects the unique_id assigned to each entity. For all of the other devices, the transition should be seamless, but not with variables.
Long story short: Home Assistant has a memory of the old entities, which don’t exist any more (because the unique_id changed) and also created duplicates (_2 is Home Assistant’s way of managing duplicate names).
To Fix: Delete the old entities from the Entity Registry manager, then rename each of the new ones by removing the _2 from the entity_id and all of your displays should start working again.
Very cool. I was just reading about the ability to have 2 ISYs, which I just happen to have! So I will be looking forward to seeing how this works.
Cheers!
Bob
@shbatm, I was able to resolve the unique_id issue pretty easily. I did the update in HACs, but before rebooting I deleted the core.entity_registry file. It took 2 reboots to clean everything up, but now I have everything working with minimal effort on my part. Now running 1.2.1 and very happy.
BTW, for anyone else using the HACS interface and running HASSIO on a Raspberry Pi, do not use the system restart in HACS after doing an upgrade. For Hassio/Pi, you need to do a full reboot. Otherwise you will have errors on restart.
Congratulations on the integration of your work into the main release! I know this took a lot of effort and time from you. But I think this is a huge step forward in terms of long term support of the ISY integration. Well done, sir!
I just updated to .110 and saw that the ISY integration had gone through some major upgrades so I decided to pull my ISY out of storage and try it again with my Insteon devices. Everything went swimmingly except that my two Insteon Micro open/close modules that I’m using with some roller shades are populating as sensors.
The modules are 2444-222 and I’m hoping that it’s just something I missed in setting things up.
I noticed in the release notes that the on/off control had changed from a switch to a sensor. So maybe they won’t work as open close anymore.
I’ve also tried creating the program like the documentation discusses for HA.cover but that does not seem to be picked up by the integration anymore. Even though I’ve tried several times removing and recreating the integration hoping to pick up the program “device”.
Any suggestions or thoughts would be great.
Thanks
Thanks for giving it a try and reporting back!
Can you please use a web browser to go to “http://your-isy-ip/rest/nodes/INSTEON-ADDRESS-OF-MICRO” and post the XML file here? That will help me tweak the sorting. Also, what firmware version is your ISY? Is it 4.x.x or 5.0.x?
Side note: even if they are picked up as sensors and we can’t get the sorting to work, you can still use the isy994.send_raw_node_command service to send DON (on) and DOF (off) commands to a sensor. A Home Assistant Template Switch would allow you to assign these as the regular on/off commands.
This is definitely still supported (it’s how I use my garage door IOLinc). Are you seeing any errors in your Home Assistant log? If it’s finding them but refusing to add them you should see something like:
"WARNING Program cover entity 'SOME NAME' not loaded, invalid/missing status program."
Just for clarity, you should have a folder called HA.cover, inside of that a folder called MyCover or whatever, and in that folder you should have two programs; one named actions and one named status.
Firmware is 5.0.16C
Both modules report similar XML just changes for the different names and such.
<?xml version="1.0" encoding="UTF-8"?>
<nodeInfo>
<node flag="128" nodeDefId="DimmerMotorSwitch_ADV">
<address>20 1C 52 1</address>
<name>Master Bedroom Window</name>
<type>14.1.67.0</type>
<enabled>true</enabled>
<deviceClass>0</deviceClass>
<wattage>0</wattage>
<dcPeriod>0</dcPeriod>
<startDelay>0</startDelay>
<endDelay>0</endDelay>
<pnode>20 1C 52 1</pnode>
<ELK_ID>C03</ELK_ID>
<property id="ST" value="0" formatted="Off" uom="100" />
</node>
<properties>
<property id="DUR" value="163" formatted="16.3 seconds" uom="58" prec="1" />
<property id="OL" value="255" formatted="100%" uom="100" />
<property id="RR" value="28" formatted="28" uom="25" />
<property id="ST" value="0" formatted="Off" uom="100" />
</properties>
</nodeInfo>
The HA.cover issue was me. As usual when I’m creating ISY programs I missed hitting the save button at some point in the process…
Thanks!
Now that the excellent work by @shbatm is mainline, should we still be using the HACS version? Is there ay advantage in doing so?
@tendiian – I can have this added as a cover (changes already staged here). Question for you though since this thread got me nowhere… Can you send a particular open % to this device, or is it just ON/OFF?
For example – does the REST command below command it to go to 50% or full open?
http://your-isy-ip/rest/nodes/20 1C 52 1/set/DON/128
@pashdown: Short answer: No, you don’t need the HACS version**. See original response here:
**If you want to continue testing, the next “phase” is to move the PyISY module to asynchronous code to try and speed up the communications. That is available on the 2.0.0b1 beta HACS release right now, but as soon as it’s stable it’ll be merged to Core as well. That will likely be my last major HACS update since that’s the end of the roadmap laid out for PyISY updates, anything else will be pushed to Core (including @tendiian’s micro open/close support).
I finally updated to the newest HA and ISY944 Integration. A couple issues worth noting:
None of my HA.binary_sensor or HA.lock programs came across. I had them working just fine before upgrading to 0.110.3 but none of the binary sensors are created after upgrade. I checked and see no errors. I will increase logging to see if I can tell what is going on.
Most of my variable icons defaulting to “mdi:counter”, but easily fixed in customizations. I am guessing that is normal behavior.
Home Assistant 0.110.3
Try restarting HA one more time… Someone else mentioned this but they showed up after a restart. I just confirmed that all of my programs are loading (ISY 5.0.16C, HA 0.110.1) and functioning correctly.
This is the default behavior now. There are different default icons for Groups/Scenes, Variables, and Programs to semi-mimic the ISY’s UI; they should all be customizable within Home Assistant.
Still no joy. I have tried numerous reboots, even restarting the ISY a couple times, and for some reason Home Assistant no longer reads the Binary sensors from ISY Programs. I did not change anything at the ISY side, just the upgrade to 0.110.3
I am not seeing any warning or error messages in the Log.
Confirm you’ve checked the States page too just to make sure the name didn’t change to something else?
Correct, I have checked all devices to make sure it was not a name change. All 8 of the Binary Sensors that were being created by HA.binary_sensor programs have disappeared. Also, the 2 HA.lock programs are missing in HA as well.
Can you PM me your /rest/programs?subfolders=true XML file?
@shbatm
Sorry I got tied up with work just tested this now and it worked perfectly.
http://your-isy-ip/rest/nodes/20 1C 52 1/set/DON/128
<RestResponse succeeded="true">
<status>200</status>
<reason code="0"/>
</RestResponse>