Thanks @teharris1 for your reply.
To the end user of the thermostat, the result will be the same with both architectures? Will the native thermostat work the same as the MQTT thermostat and the bridge?
I’d love to hear if someone was using the MQTT integration and migrated to the native component, if they found any major benefits. That would be useful also when the component will be finalized, to encourage adoption and give prominence to your hard work.
I’ve used both insteon_mqtt and insteon2 component extensively (and a year or so ago I used the initial insteon implimentation in HA)…
Insteon_MQTT is a great solution that I used for nearly a year… it answered many of my pain points… but i found it’s initial configuration to be a bit cumbersome and nit picky. But once setup… it was pretty much rock solid. It had two main draw backs and two benefits over insteon2.
i found a few memory leaks that would expose themselves once every couple of weeks… the developer seems to be happy with his impl and isn’t pushing updates too frequently any longer
db sync and “cascading state changes” is a built in feature, but i did not find it to work that well. Maybe i had a configuration issue because no one else seemed to have any issues… but insteon2 worked immediately on “unboxing”
being a seperate service, when restarting HA, the insteon network and states were not affected… the persisted MQTT state came back very quickly and HA boot time was < 30 seconds. With insteon2, i’ve found startup to be pretty quick… but i am aware that states might not be accurate for a few minutes (up to 10)
insteon_mqtt had the ability to call the SET button on devices, download databases, and make modifications to not just the modem, but anything on the network… making remote administration much easier
Thanks for the answers. I think the memory leaks in insteon_mqtt are a show stopper for me.
I will wait for the inclusion of the insteon2 component, the great effor put in by @teharris1 and the new features in roadmap (UI configuration panel) will be worth it.
Hi everyone, my first PR will not make it into 0.110 unfortunately. The core team is a bit behind in reviewing pull requests at the moment. I am hopeful it will make it into 0.111 in a few weeks. The code has been reviewed but not approved so the likelihood it makes it into 0.111 feels pretty high.
Good news. The PR just got approved (but not merged yet). This means it is almost guaranteed to be in 0.111.
For those of you who may have had issues installing the custom component while waiting for it to make it into the core, I found a way to install pyinsteon from the custom component itself. So you can download insteon2 again and it will install the dependencies automatically.
Looks like this is going to make it into 0.110 after all. However, it will not include the Thermostat element. I added the thermostat pull request yesterday so hopefully that will make it into 0.111.
@wes would you mind plugging your SmokeBridge in and reloading insteon2 custom component again? I have made changes and I can confirm it will load in HA correctly but I cannot test if the sensors work as expected. If that is too hard I am not too worried about it.
i see 110 is out – is there any way to port my device config/db caches over from the insteon2 custom component to the main service before i upgrade? or am i reconfiguring each device and entity name?
Hi. The SmokeBridge has been plugged in all along. By coincidence I upgraded to insteon2 dated May 18. What should I look for ?
@teharris1 thanks for the work on this. I’m interested in seeing if there’s a way to get the fast on/off events and dim/brighten events from the remotes and switches. I still have an Indigo installation kicking around on an ancient Mac Mini, largely due to the ability to receive the fast on/fast off/dim start/dim end events. I see the new pyinsteon library has support for it, but I can’t tell if it’s bubbled up to the home assistant layer yet or not.
EDIT: forgot to mention - I have a spare PLM that I purchased just for development that I can run some tests on if that helps.
Got the following new warnings after upgrading from .109.6 to .110:
11:00:49 AM – Switch (WARNING)
Light is deprecated, modify InsteonDimmerEntity to extend LightEntity
11:00:49 AM – Light (WARNING)
CoverDevice is deprecated, modify InsteonCoverEntity to extend CoverEntity
11:00:49 AM – Cover (WARNING)
ClimateDevice is deprecated, modify InsteonClimateEntity to extend ClimateEntity
11:00:49 AM – Climate (WARNING)
BinarySensorDevice is deprecated, modify InsteonBinarySensorEntity to extend BinarySensorEntity
11:00:49 AM – Binary sensor (WARNING)
I now have your latest insteon2 installed. Nothing new shows up in HA (sensors…) that I can find.
@wes, those warnings can be ignored. I had to “down grade” the custom component to work with 0.109 but it also works with 0.110 +.
@geoffdavis Fast On/Off work in HA as event insteon.button_on_fast and insteon.button_off_fast.
I was mistaken about this being released in 0.110. It will be 0.111. It was pulled into the dev branch last week so I thought it was in 0.110 but in fact it was targeted for 0.111.
Regarding the migration from insteon2 back to insteon when 0.111 comes out, if you keep your configuration directory, and just change the configuration.yaml entry back to insteon rather than insteon2, all of the devices will quickly show up in HA. However, you will see all of the devices with stale insteon2 entries as well. The simplest thing to do is to delete the stale entries.
If, for any reason, you want a “clean” reset of the system, you can delete the .storage directory inside the configuration directory. This will clear out all entity data. This will also require you to reapply any integrations you have entered using the UI (i.e. Configuration -> Integrations) as that will be lost in this approach.
Also, the Thermostat is not currently approved. I believe that will likely go into 0.112 but I will let you all know if that changes.
Does that mean my entity names will all be on the old insteon2 entities?
Disregard what I said about the entities. I was confusing the situation after I get the configuration flow in place. The entity names in the custom component will stay the same when you go back to the main component. Sorry for the confusion.
Cool, I’ll give it a go when 111 releases
Unfortunately I was right the first time, When you convert from insteon2 back to insteon the “old” insteon2 entity will still exist and a new insteon entity will be created.
Notice how the first one is active and the second one is grayed out. The second one is associated with insteon2 and will need to be removed from HA.