Core: Insteon_hub API usage

[balloob]

We have gotten a complaint from Insteon about our implementation of the Insteon Hub. They want us to use the streaming API instead of polling each device every 30 seconds. Very understandable and migrating to a streaming API should improve speed of updates and load on all involved devices/services. We need to get this addressed or I will have to disable the component.

I will disable this component in the 0.32 release unless this issue has been addressed (currently scheduled for November 5).

_(Note, I initially wrote wrongfully November 11, but 0.32 will be released on November 5)_

From Insteon:

We've also seen that the way the application is currently architected it appears to request device statuses in a loop, each device getting a get_status request every 30 seconds. The correct approach to monitoring for device status changes is for your application (or application servers or hardware interface) to open a connection to our streaming endpoint (http://docs.insteon.apiary.io/#reference/houses/house-device-activation-stream) and listen for device status messages. Discrete device status requests can be made as a fallback mechanism or when the user takes specific actions that would benefit from having a status update. Repeated get_status requests serve only to increase the volume of Insteon traffic within the user's home, saturate the Insteon Hub, and put additional load on our servers/services, all of which actually degrade the performance of the application.

CC @FreekingDean, @haraldnagel, @wkonkel, @teagan42.

[Teagan42]

I would also suggest, that when we make this change, we allow users to
connect directly to the hub without going through insteon cloud - that
would help with lag and improve useability. I'll see if I can work on this
in the next week or two, but I have been CRAZY busy lately - haven't even
had time to see what was added in 0.30!

On Mon, Oct 10, 2016 at 11:55 PM, Paulus Schoutsen <[email protected]

wrote:

We have gotten a complaint from Insteon about our implementation of the
Insteon Hub. They want us to use the streaming API instead of polling each
device every 30 seconds. Very understandable and migrating to a streaming
API should improve speed of updates and load on all involved
devices/services. We need to get this addressed or I will have to disable
the component.

_I will disable this component in the 0.32 release unless this issue has
been addressed (currently scheduled for November 11)._

From Insteon:

We've also seen that the way the application is currently architected it
appears to request device statuses in a loop, each device getting a
get_status request every 30 seconds. The correct approach to monitoring for
device status changes is for your application (or application servers or
hardware interface) to open a connection to our streaming endpoint (
http://docs.insteon.apiary.io/#reference/houses/house-
device-activation-stream) and listen for device status messages. Discrete
device status requests can be made as a fallback mechanism or when the user
takes specific actions that would benefit from having a status update.
Repeated get_status requests serve only to increase the volume of Insteon
traffic within the user's home, saturate the Insteon Hub, and put
additional load on our servers/services, all of which actually degrade the
performance of the application.

CC @FreekingDean https://github.com/FreekingDean, @haraldnagel
https://github.com/haraldnagel, @wkonkel https://github.com/wkonkel,
@teagan42 https://github.com/teagan42.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC2fZeeP-8LDHxN5eOcV_7SFA13Uwor6ks5qyyTOgaJpZM4KTRQc
.

[FreekingDean]

@Teagan42 The direct connection approach would be nice! The big annoyance around direct connection is that you need to send the "I want to get info about X device command" then wait for a response. And you must not interrupt it with any other commands :(.

[Teagan42]

Good to know - well, it'd be a nice to have but not needed. I don't even
have an insteon hub anymore, so be hard to test any changes.

On Tue, Oct 11, 2016 at 8:10 AM, Dean Galvin [email protected]
wrote:

@Teagan42 https://github.com/Teagan42 The direct connection approach
would be nice! The big annoyance around direct connection is that you need
to send the "I want to get info about X device command" then wait for a
response. And you must not interrupt it with any other commands :(.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-252927963,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC2fZbn_k1eSwHHJjZ-hfWfHsRRvfAmPks5qy5jygaJpZM4KTRQc
.

[FreekingDean]

Totally! It seems that with this version of the HUB they wanted to move away from direct access (I say that because it seems their documentation shifted to using the REST API). I would assume that using the SSE/stream would be the best route as I hope they have some well cached, handled state change arch. in the cloud infrastructure that runs their API. This way any streaming updates are sent directly out rather than polled in. Hopefully resulting in little to no load on the individual HUB's :)

Sorry about the word salad, I'm still drinking my morning coffee :)

[balloob]

Thanks for the quick responses. I hope we can get this resolved soon.

The Wink component is a good example to base it off. The general architecture is like this:

• Insteon Hub component will need a new streaming status class that holds the current Insteon Hub state. It will fetch the current state and listen to the updates that come in from the stream. After each update it will update the current known status and notify involved entities.
• Based on which devices are known, fire discovery events to load up the appropriate platforms
• Each entity (sensor/switch/etc) will be subscribed to an instance of the streaming status class for updates. When an update comes in, the entity will call update_ha_state(True).
• Change the entity property should_update to False (so HA doesn't call it)

[Teagan42]

I may have time next week to work on this. I have parent teacher
conferences, my dad's retirement party, bowling league, work projects and
personal projects this weekend.

On Tue, Oct 11, 2016 at 9:16 AM, Paulus Schoutsen [email protected]
wrote:

The Wink component is a good example to base it off. The general
architecture is like this:

• Insteon Hub component will need a new streaming status class that
  holds the current Insteon Hub state. It will fetch the current state and
  listen to the updates that come in from the stream. After each update it
  will update the current known status and notify involved entities.
• Based on which devices are known, fire discovery events to load up
  the appropriate platforms
• Each entity (sensor/switch/etc) will be subscribed to an instance of
  the streaming status class for updates. When an update comes in, the entity
  will call update_ha_state(True).
• Change the entity property should_update to False (so HA doesn't
  call it)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-252948122,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC2fZRj0mBlZXsHwHLCfcUWI5QC3LAohks5qy6hogaJpZM4KTRQc
.

[Teagan42]

Question though: Wink doesn't look like it's using SSE (
https://github.com/MHendricks/py-wink/blob/master/wink/api.py), just a hub
that doesn't poll.

Do you know of a good library for SSE streams? I have time to work on this
a little tomorrow and thursday it looks like

Dean, how do you want to handle this? Do you want to update the library and
I'll update HA to consume it? (if so, I'll need some sort of contract on
what methods to call/data to expect)

On Tue, Oct 11, 2016 at 11:51 AM, Teagan Glenn teagan.m.[email protected]
wrote:

I may have time next week to work on this. I have parent teacher
conferences, my dad's retirement party, bowling league, work projects and
personal projects this weekend.

On Tue, Oct 11, 2016 at 9:16 AM, Paulus Schoutsen <
[email protected]> wrote:

The Wink component is a good example to base it off. The general
architecture is like this:

• Insteon Hub component will need a new streaming status class that
  holds the current Insteon Hub state. It will fetch the current state and
  listen to the updates that come in from the stream. After each update it
  will update the current known status and notify involved entities.
• Based on which devices are known, fire discovery events to load up
  the appropriate platforms
• Each entity (sensor/switch/etc) will be subscribed to an instance
  of the streaming status class for updates. When an update comes in, the
  entity will call update_ha_state(True).
• Change the entity property should_update to False (so HA doesn't
  call it)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-252948122,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC2fZRj0mBlZXsHwHLCfcUWI5QC3LAohks5qy6hogaJpZM4KTRQc
.

[FreekingDean]

That sounds good @Teagan42, it looks like Wink uses pubnub, which is a different streaming protocol. Hopefully we can mimic that type of solution :)

[FreekingDean]

Their streaming endpoint has a 60 second timeout, are we sure that it is the best use case for this?

[FreekingDean]

Got an email from Insteon

If you application is trying to monitor the status of devices who's state will be exclusively changing due to api commands or phone app interaction, then the streaming endpoint will not work for you (well at least not yet).

...

If you have a lot of users using your app who also have a lot of devices each, then you may want to implement so some staggering logic so that your system does not try to refresh all of your users's devices simultaneously.

They had also said they were not sure about who sent the email, but they do not believe this should be an issue. If you want to CC me on the thread I might be able to ask better questions about their suggestion.

I don't think implementing their suggested change (device-activation-stream) is the best approach. It has a 60 second timeout, and only handles state changes at the physical device level, not from any API/App based state change.

[balloob]

Okay, that does indeed seem like the stream API endpoint would be of little use to do a full system integration.

Do they have an API endpoint that fetches all device statuses at once? That way we could at least limit the number of requests.

If they don't have that we could always queue up all device updates and throttle requests to one per 30 seconds. It would make the integration kinda useless from a home automation perspective. If we go down this last route we should add a big fat warning to the docs. I would hate to see people buy an Insteon Hub because of the Home Assistant integration and be presented with a bad experience.

[Teagan42]

No, you get a list of devices, then you use those device ids to get each
device state:

http://docs.insteon.apiary.io/reference/devices/devices-collection/list-all-devices
http://docs.insteon.apiary.io/reference/devices/device/retrieve-a-device

On Tue, Oct 11, 2016 at 8:17 PM, Paulus Schoutsen [email protected]
wrote:

Okay, that does indeed seem like the stream API endpoint would be of
little use to do a full system integration.

Do they have an API endpoint that fetches all device statuses at once?
That way we could at least limit the number of requests.

If they don't have that we could always queue up all device updates and
throttle requests to one per 30 seconds. It would make the integration
kinda useless from a home automation perspective. If we go down this last
route we should add a big fat warning to the docs. I would hate to see
people buy an Insteon Hub because of the Home Assistant integration and be
presented with a bad experience.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-253100501,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC2fZVuD22L_flrGrLpSCLYeVbtWcQFXks5qzEMcgaJpZM4KTRQc
.

[FreekingDean]

Agreed @balloob I think client experience is our focus. If we haven't heard from anyone in particular about home-assistant sending too many requests. It does seem that we can fetch multiple devices via a scene though! I will look deeper into this :) http://docs.insteon.apiary.io/#reference/scenes/scene/retrieve-a-scene

[Teagan42]

That assumes that all the devices are in a scene...

On Wed, Oct 12, 2016 at 5:51 AM, Dean Galvin [email protected]
wrote:

Agreed @balloob https://github.com/balloob I think client experience is
our focus. If we haven't heard from anyone in particular about
home-assistant sending too many requests. It does seem that we can fetch
multiple devices via a scene though! I will look deeper into this :)
http://docs.insteon.apiary.io/#reference/scenes/scene/retrieve-a-scene

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-253192818,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC2fZaQIc9XfkGlM-DLcRCHjtwTzswydks5qzMnfgaJpZM4KTRQc
.

[FreekingDean]

Exactly, which we could create/check for in order to make a better exp, by only adding a new scene called "All Devices" or something of the sort. You can also mark scenes as invisible :). I think we should create a home-assistant-all-devices scene that is invisible and holds each device.

On startup insteon-hub will either find, or create the scene that includes every device.

[Teagan42]

So, then, really there is no need to change the insteon-hub library, this
change could be done via Home Assistant. I think this would probably be the
easiest/most efficient path to a better UX

On Thu, Oct 13, 2016 at 9:19 AM, Dean Galvin [email protected]
wrote:

Exactly, which we could create/check for in order to make a better exp, by
only adding a new scene called "All Devices" or something of the sort. You
can also mark scenes as invisible :). I think we should create a
home-assistant-all-devices scene that is invisible and holds each device.

On startup insteon-hub will either find, or create the scene that includes
every device.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-253544943,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC2fZQvog5-EEVMD9DOSQ8dQGMEbd32bks5qzkvsgaJpZM4KTRQc
.

[FreekingDean]

I do need to add a little support for creation/manipulation of scenes. After that I can take a look at HA though!

[balloob]

Just a reminder that 0.31 has been released yesterday. As I stated in the issue description, we will have to disable the Insteon hub integration as of the next release (scheduled November 5) if this issue is not addressed.

_(Note, I initially wrote wrongfully November 11, but 0.32 will be released on November 5)_

[robbiet480]

We are 4 days from release and no movement has been made on insteon_hub so it looks like it will be getting disabled 😿

[balloob]

Starting with release 0.32, the Insteon Hub will no longer be available as an integration until this issue has been resolved.

[phareous]

I've been working on a library to talk to the hub locally..I've got it controlling lights but am working on scenes, adding devices, etc. I planned to work on the hass side after the library is done but if anyone wants to help it would go faster since I'm not familiar with the hass internals yet.

I think this would be a good thing to have since insteon has stopped giving out api keys or delaying months..It's just not reasonable to expect end users to apply for keys and either not get them or wait months and months.

Anyway if anyone wants to collaborate with me let me know

[balloob]

That's great news @phareous . Our existing implementation was only targeting lights.

Is your library available online?

[phareous]

Yes it's on github but I need to commit the latest..let me clean it up and.document over the next day or.two and I'll post an update here

[phareous]

@balloob Here is the library... if you have any questions msg me here or email [email protected]

https://github.com/phareous/insteonlocal

[phareous]

I also added it to the python package index as insteonlocal, version 0.1

[camrun91]

I have the insteon hub that is able to use the API/Cloud based stuff. I never did get a developer API key from Insteon so I went a different route with this. I am currently running OpenHab only for insteon hub support then have custom componets for the switches and dimmer modules I have. This works great and connects to the hub directly. It would be neat to have similar built in function with Insteon in Homeassistant

[craigjmidwinter]

@phareous, any movement on getting this working with Home Assistant?

I'm using openhab 1.8 exclusively right now, but it appears that Openhab 2 Insteon support is busted because of a java library, so I'm considering switching to Home assistant. Like you, I haven't worked with the hass internals at all, so I don't know if I'd be much help there, but I could probably work on thermostat stuff

[phareous]

No I haven't looked at the HASS stuff yet...I'm still working on the library in what little spare time I have. I am working on trying to be able to automatically add devices to the hub and to create and manage groups. This stuff can be done via the insteon app so its not the end of the world if I can't figure it out...but still I'd like to try to solve it and doing so will give me a better understand of how the insteon protocol works. I'm also working on constantly improving the buffer reading and parsing, which will be needed for picking up manual switch changes. Also this is my first python library (I'm a PHP developer by trade) so I'm having to sometimes go back and revise things to be better. Anyways, it is unfortunately a slow process because of other personal things going on in my life, I only have an hour here or there each week for this, so I forsee it taking weeks yet..

[phareous]

Also @wardcraigj I may be able to help you figure out the thermostat codes, I just don't have any hardware at all to test it with. I'll probably be going ecobee3 in my new house so I will probably never be able to test that part

[terrycarlin]

I can also help out with the Insteon Messages and testing. I have written a lot of python to directly control my Insteon Hub. Unfortunately, the code is not pretty and may not be useful to others.
I have several light switches, appliance switches, leak detectors, door sensors, motion detectors, and an IOLink setup controlling my garage door that I can use for testing code..

On Nov 23, 2016, at 8:22 PM, phareous [e-mail] wrote:

Also @wardcraigj https://github.com/wardcraigj I may be able to help you figure out the thermostat codes, I just don't have any hardware at all to test it with. I'll probably be going ecobee3 in my new house so I will probably never be able to test that part

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-262681722, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1W1Pzptga4WfNYsFwUM5sGAXEdj_0Xks5rBQLugaJpZM4KTRQc.

[hax0rmort]

I can test, perhaps I have a device type someone does not. I have a seven leak sensors, dimmers, appliance modules... and open/close + 2014 insteon hub and usb plm. I'll sub and watch for an opportunity to help, i don't code but am looking to jump from a broken Vera Plus/Insteon/Wink implementation to either OpenHab or HA, but I absolutely HAVE to have Insteon support now, can I get either with the hub? I've been restricted to using the usb plm with vera flying blind, not as cool for an enduser as the hub with the app....

thanks all. oh, so i saw someone mentioned that due to a recent java bug that insteon support is broken in openhab today? right or wrong?

[craigjmidwinter]

@hax0rmort re: Insteon support in openhab-- The issue I observed in openhab only impacted v2, I was able to get all my devices working in 1.8.

[craigjmidwinter]

I had a little time to look at this today, and I managed to use @phareous's insteonlocal library loaded in during the set-up. The device class that I set-up seemed to be working and I was able to use it to communicate with my lights from within the setup function, but for some reason the devices don't get state cards in the ui. This is the first time I've worked on this project and I'm also not super familiar with python, so unfortunately, I'm not exactly moving too quickly through this.

I'm not going to have a whole lot of time that I'll be able to dedicate to this in the next two weeks, so if someone with a bit more experience wants to take a look at the diff and see if the problem stands out to them, it wouldn't hurt-- https://github.com/home-assistant/home-assistant/compare/dev...wardcraigj:insteon-local

[FreekingDean]

Hmm. I did a little basic research into this and I want to call some things out.

Around the original issue, I had chatted with the Insteon Dev support group, they were unaware of an email to us surrounding load on their servers. I don't think their email was a complaint (as far as what I was told) as much as a suggestion. The large issue at hand is we are putting too much load on the USERS Insteon hubs.

So with the problem being:
How do we reduce load on a users Insteon hub.
I don't believe the insteon-local approach will actually do anything different. It will instead of contacting the Insteon Cloud API hit the Insteon hub directly. This may actually increase load on the Hub as the Cloud API may have better/more direct strategies for gathering command based info.

I had previously suggested we use the Insteon Scene functionality and I had tried a few methods to get it working, and realized the data I was getting back was not actually status of the device but configuration settings. (tl;dr we can't use scenes to accomplish this)

I have come up with a new plan of attack! It even uses the streaming endpoint! (Woo! 🎉)

Use the streaming endpoint to listen for physical events. (I will handle this via the package)
Cache device status of a successful command sent to Insteon.
Every X-minutes/hours/etc. Do a hard ask on the hub to get device info. (This will give us knowledge of outside API device status changes)

This should reduce calls on our Users hubs by A LOT, it will also allow a fallback for outside API device interference stuffs.

I'd love some feedback on the concept, as I am testing it out now!

tl;dr
The insteon-local method doesn't actually solve the problem at hand.
Device stream will if were super smart about it.
Testing now, will report back.

[FreekingDean]

Also want to apologize for being so absent this past month. It was a doozy for me.

[phareous]

Well this really doesn't solve the issue of insteon not handling out API keys anymore... all this work you're doing will only work for people who already got the key. Any new users will be shut out, myself included. It's been two months and they still haven't sent me a key. You could solve all of that by hardcoding the key in the source code, but I'm guessing since its open source, Insteon wouldn't be too agreeable to that.

Polling the hub if done right shouldn't be a major problem as other software does it just fine (openhab, homeseer, etc.), though I don't know specifically how often they query, etc.

Several of us are working on local support... if we get it working we can look into scenes. Actually the local library already supports using scenes, I just haven't figured out how to modify them via api calls (but not a huge deal as scene setup could be done via insteon app)

[phareous]

Also I see they mentioned get_status, which I am thinking is the direct status request to each insteon device. The way I am planning on initially implementing instead is only to check with the hub (via the buffer), as all broadcast events, etc. go there. So the frequent polling would only be against the hub buffer, and not via individual device requests. Then could query individual devices on a less frequent basis in case it was missed (via buffer overwriting, etc.)

[FreekingDean]

Makes total sense!

I can't believe they have stopped giving out keys! That seems super anti user. I think the real solve is to nudge people away from Insteon. I actually think they have a great line of hardware, but their docs, software, and dev support needs a good chunk of work.

I actually think that we can drop the whole scene idea completely. Does the hub provide any endpoint to listen for events? This way we don't have to poll for them?

[FreekingDean]

I do want to point out that I needed to subscribe to the mailing list to get my key. I am also not super opposed to publicly giving away my key as it really isn't tied to anything besides some random information about myself. I would imagine it is frowned upon, and I don't want to lose my key now that I know they aren't giving them out, but if it helps.

[FreekingDean]

I do also want to point out that we should be coming at this from both sides! (Local and Cloud) I would love to see both as options!

[phareous]

The hub has a buffer status which contains any events/commands received by the hub. The problem is it is of limited size (100 chars in the 2012 hub, 200 chars in the 2015 hub) so it is easy for broadcast events (scene cleanup commands, etc.) to quickly overwrite the buffer. Most of these we don't really care about necessarily except to verify the command actually succeeded...but where it is very important is if someone manually toggles a switch, or they toggle it from an app outside HASS, then HASS would have no way of knowing it happened unless it constantly polls the buffer and happens to see it. This concept would be the equivalent of the zwave instant status (and that cloud streaming api)... versus actually polling every device individually and waiting for its response to come through. Should be something that could be explored once the basic on/off stuff is working. I haven't actually done much in HASS yet (Craig has) as I've been focusing my energy on the actual low-level library.

With it being open source, anyone could grab the api key out and use it for anything they like, kindof negating the "security" aspect of the keys... thus I am sure Insteon would probably shut your key down if you did that...but who knows. What they ought to have done instead of api keys is have apps be able to authenticate via oauth against their connect.insteon.com accounts

Dean since you have a huge understanding of the HASS architecture and design, do you think you could lend your talents to helping Craig with the library integration? Once we get this all working I hope to start adding more things to it, like scenes, instant updates, and more devices like outlets, thermostats, and motion sensors

[phareous]

RE: local and cloud... yes I think it would be good to fix the cloud stuff so those who are already using it can keep using it. And then have local support for everyone else. Plus the local support could eventually support things they don't have in their API, and additional device types

There is also a whole other class of local devices, the PLMs. I believe the Insteon Modem and the Insteon USB Key would work with PLM support, but I haven't focused on that because Insteon seems to be moving away from those, and while they still make them, who knows how much longer. There are some python libraries out there that could be plugged in to support them (pytomation, etc.)

[FreekingDean]

Seems right. I do know that when a physical event happens it will send a message to Insteon's cloud API, so there might(?) be something we can do around that or use that to gain more knowledge about the hubs general flow.

Agreed, I'd like to keep my keys.

I would love help Craig with some of his issues surrounding HASS implementation, though I would by no means say I have a huge understanding :P.

I would also really enjoy seeing Insteon hub & local working in unison to get the most use out of these little things.

I'll try to look at Craig's stuff tomorrow see what I can't figure out!

[phareous]

Regarding nudging people away from insteon... one thing insteon has going for it is the keypads. I haven't seen anything decent in zwave, and lutron caseta doesn't even try

[phareous]

One other thought about the keys... you could setup a proxy server that everyone used and that server would then talk to insteon in the backend. Probably not very affordable for an open source project to do, but I bet this could be how stuff like castleos and other commercial software get around the api key problem

[FreekingDean]

I was thinking about a proxy server approach. The same could probably be done for the local work you are doing assuming people want to forward ports.

I feel very odd about doing a passthrough though. However, it is totally in the back of my mind!

[hax0rmort]

Thanks for including me in the replies. I'm glad to have shook the thread
up! You all jumped in immediately to brainstorm to solve this. I read to
my limited understanding and am following along. I have the 2014+hub and
the usb plm if testing is needed. Still waiting on anyone to get insteon
hub support back. I'm really pulling for you guys! Let me know how I
could be of help if at all. Thanks.

V/r,

Tim Hasko

On Thu, Dec 15, 2016 at 00:44 Dean Galvin [e-mail] wrote:

I was thinking about a proxy server approach. The same could probably be
done for the local work you are doing assuming people want to forward ports.

I feel very odd about doing a passthrough though. However, it is totally
in the back of my mind!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-267244268,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUQDm16X_f6xXzgdokPY3PDFpTaa0hOUks5rINO6gaJpZM4KTRQc
.

--
-Sent from Gmail Mobile on iPhone

[craigjmidwinter]

Whoa! Lots of activity! I agree, it makes sense to have both cloud based and local options for Insteon support for the reasons @phareous stated and also because some users may just have a preference for local control as opposed the cloud api just for the fact that they aren't subject to the changing whims of Insteon or for piece of mind, whereas, I think the benefit of the cloud implementation is eventually getting the data from the streaming end-point as opposed to polling, and the ability to get up and running with pretty much zero conf (I could be wrong about this, but from what I can tell, we can't get the names entered by the users for devices off the hub, so name and device_id pairs need to be entered into the conf, whereas we can set-up all paired devices right off the cloud api)

Re: my work on the binding. I think it is pretty close to being ready for a PR, it looks like @phareous made an update so I'll play with it a bit more tonight. I basically copied the insteon_hub changes and re-implemented for local. The one issue that I'm not entirely sure about is that sometimes when I run it, HASS tries to set-up the light before the hub is initialized, I'm not exactly sure why, or what the best option is for solving that is

[FreekingDean]

@wardcraigj There are a few reasons for that. I can look into what exactly is going on to help.

Does the hub not have any command to list devices in the buffer?

I've been thinking more and more, and I am wondering about how sensors work with the Insteon tech. Are they supposed to be polled for information at regular intervals, or do they push up any changes? (This is mostly me thinking aloud but if someone knows I'm very interested)

[FreekingDean]

I have 2 PR's on my library for
scenes: https://github.com/FreekingDean/insteon-hub/pull/8
streams: https://github.com/FreekingDean/insteon-hub/pull/7

I would love more eyes on it if anyone has time.

[phareous]

Dean...yes you can query the hub for a list of devices, but they do not have any friendly names or user-supplied data..its just a list of device ids and their models. I have a translation in my library that will convert that back to a friendly model name and type... but we won't know what room they are for, etc. NOTE: This is only for linked devices so we assume they already added them via Insteon mobile app, etc.

For the sensors I believe they just report to the hub so you would have to query the hub buffer regularly to look for them. You can't query the devices directly as they go into battery saving mode

[phareous]

Craig: We could write a helper script to call getLinked and then write out a sample config, then the person just goes in and puts in the friendly names

[xstrex]

Dean, I can confirm that Phareous is correct about the sensors. They will send an update to the hub when something is triggered, and they can not be polled directly. They do this to conserve battery power.

[craigjmidwinter]

@phareous, yep, that would work. I think we will need device-id:name pairs in the config no matter what, so in the end, it is probably faster to create the dimmers using the values in the config, since there are a few sleeps involved in getting the linked devices

[phareous]

@wardcraigj Right, the getLinked() would be a one-time setup step (or something they run manually when they add devices), as it would be too slow to run automatically during normal HASS operation

[FreekingDean]

I think that setup is easily something that should be done outside of HASS boot/automated process but there are really cool things you can do with HASS to set them up in app!

[camrun91]

One thing I can think of is does the list of supplied devices include the device name and device details? one of my switches in the app is id 3b.db.e2 and then has a device details that is in the form of x00x0ax00. Could these alone be used to set up the devices using one of them as the default "frendly name" then prompt the user to change the friendly names after it is auto set up?

[phareous]

No it only includes the model number, category, and firmware revision. I have JSON files in the library that can translate these to actual product names. See the example script and the getLinked() method

[craigjmidwinter]

Yeah, I was thinking about this. I maybe set it up with a configure prompt like plex and hue, and step the user through each of the lights and make them blink so people don't have to try identify them by id? Maybe that will be a goal for the next iteration of this component since we're pretty close to putting together a PR for manually configured lights

[phareous]

Someday I want to be able to use the local library to link devices but I never got very far... Their docs are horrible and out of date

[camrun91]

@wardcraigj That would be really cool and I feel like we will have a PR ready with in the next few days. Then we can work with @phareous on getting more products supported. I think it would be awesome to be able to do fanlincs and I/O devices.

[craigjmidwinter]

Yep, thats the goal. I've got the thermostat at home, so once we get lights merged in, I'd like to see if I can help get the thermostat up and running, but a friendlier device add process is definitely on my radar

[camrun91]

I currently do not have any other devices but now that I know this is being worked on there are a few that I have been holding off on purchasing that I may no go for.

[camrun91]

I have made a slack channel specifically for this issue if anyone that is working on it would like to join https://hass-insteon.slack.com/signup

[balloob]

@camrun91 we use Gitter for Home Assistant and it allows you to create rooms too

[camrun91]

@balloob ok cool we will move over to there I just created that today so no big deal.

[camrun91]

looks like we have a repo for this that is very close to being ready for a PR. Right now it only is working for switches and dimmers/lights

[craigjmidwinter]

This PR might not get merged until after winter break but in case anyone is eager to get Insteon up and running, it adds local support for Insteon: https://github.com/home-assistant/home-assistant/pull/4976

[hax0rmort]

Wow, that is fantastic news!

To be clear, this will populate and show info from any device from the hub?
I'm mainly concerned about the Inseton leak sensors. I use those
primarily. Thanks

On Sun, Dec 18, 2016 at 15:48 Craig J. Ward [e-mail]
wrote:

This PR might not get merged until after winter break but in case anyone
is eager to get Insteon up and running, it adds local support for Insteon:

4976 https://github.com/home-assistant/home-assistant/pull/4976

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-267845489,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUQDm14yuhDVXcTqUJb7XH_AcKsw9PlVks5rJZwAgaJpZM4KTRQc
.

--
-Sent from Gmail Mobile on iPhone

[craigjmidwinter]

This adds support for dimmer and switch category devices as per @phareous's Insteon local library. We haven't looked at sensors yet, but if they are basically like switches but one-way (ie, just binary state) it would probably be fairly easy to implement.

[hax0rmort]

awesome all, thanks for sensor info, great to have lighting at this point
and hub communication. yes, the leak sensors are wet/dry only, no other
state. (unknown, technically....) thanks all

On Sun, Dec 18, 2016 at 4:01 PM, Craig J. Ward [e-mail]
wrote:

This adds support for dimmer and switch category devices as per @phareous
https://github.com/phareous's Insteon local library. We haven't looked
at sensors yet, but if they are basically like switches but one-way (ie,
just binary state) it would probably be fairly easy to implement.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/3811#issuecomment-267846311,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUQDm9dtfQRLltDOEE8V-oXL1bRAC6Meks5rJZ8ggaJpZM4KTRQc
.

--

-Sent from NSA_VAN6

[FreekingDean]

Just want to throw my addition in, I have insteon-hub (cloud) working. I am just adding a bit of extra checks to make it a bit more rugged.

[camrun91]

@FreekingDean your PR still is using the API keys right?

[FreekingDean]

Correct, that is the only way to integrate with Insteon's cloud services ATM

[broux2]

I am a current openhab user and am not incredibly happy with that system so I am looking at Home Assistant as an alternative. With that said, has anyone looked at the insteon binding for openhab to aid in the development here? https://github.com/openhab/openhab/wiki/Insteon-PLM-Binding

It works fairly well and has support for many device types such as lights, thermostats, fanlinc and more.

[FreekingDean]

https://github.com/openhab/openhab/wiki/Insteon-PLM-Binding
* UPDATED LINK *
Hi @broux2 we do have some looking into using insteon's PLM bindings which will be serviced as insteon-local. I am still working with Insteon to try to leverage their cloud services.

[Jeff-Lewis]

@broux2 here's a Pull Request for insteon-local

[broux2]

Thanks Jeff. Looks like it is coming along. Adding sensors suck as contact and water should hopefully be pretty straight forward as only the status is needed.

[cyturralde]

So newbie question. How do I add the local insteon repo to my current homeassistant install? Or do I have to wait until it is added to a public release version of HA?

[craigjmidwinter]

@cyturralde -- for your install, did you clone from github or install with pip? If you cloned, insteonlocal is in master as of two days ago, so you can just pull the change down. If you installed with pip, I think you'll need to wait until the next release. Not sure what the timeframe on that is, but it seems to be pretty frequent

[cyturralde]

@wardcraigj -- I used pip on Windows 7. It would seem however that I have an IRIS hub which is apparantly different somehow ( I am new to all of this in case you couldn't tell) and isn't supported, which sucks. I would have thought they were damn near identical.

Also, thanks for the quick reply man.

[phareous]

@cyturralde the insteon hub is pretty cheap...$50-60 should you ever decide to try it

[craigjmidwinter]

@cyturralde Does iris support insteon devices?

[broux2]

@wardcraigj As far as I know it does not.

[camrun91]

Just for anyone wanting to if you installed via PIP you can get the master dev branch wich includes insteon_local by running this.
pip3 install --upgrade git+git://github.com/home-assistant/home-assistant.git@dev

[natefanaro]

Tried the above command to use the dev branch. Was getting an error. I had to add poll_hub: 1 to my insteon_hub config. Also addied import threading to the top of components/insteon_hub.py and that fixed it. I can see my switches. No open/close sensors or my IOLinc are listed. (not sure if they are supported)

This was the error I was getting after adding poll_hub to my config and before adding import threading to insteon_hub.py.

Jan 11 05:40:38 raspberrypi hass[21961]: INFO:homeassistant.bootstrap:Setting up insteon_hub
Jan 11 05:40:41 raspberrypi hass[21961]: ERROR:homeassistant.bootstrap:Error during setup of component insteon_hub
Jan 11 05:40:41 raspberrypi hass[21961]: Traceback (most recent call last):
Jan 11 05:40:41 raspberrypi hass[21961]: File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/bootstrap.py", line 151, in _async_setup_component
Jan 11 05:40:41 raspberrypi hass[21961]: None, component.setup, hass, config)
Jan 11 05:40:41 raspberrypi hass[21961]: File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__
Jan 11 05:40:41 raspberrypi hass[21961]: yield self  # This tells Task to wait for completion.
Jan 11 05:40:41 raspberrypi hass[21961]: File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
Jan 11 05:40:41 raspberrypi hass[21961]: value = future.result()
Jan 11 05:40:41 raspberrypi hass[21961]: File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
Jan 11 05:40:41 raspberrypi hass[21961]: raise self._exception
Jan 11 05:40:41 raspberrypi hass[21961]: File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
Jan 11 05:40:41 raspberrypi hass[21961]: result = self.fn(*self.args, **self.kwargs)
Jan 11 05:40:41 raspberrypi hass[21961]: File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/insteon_hub.py", line 62, in setup
Jan 11 05:40:41 raspberrypi hass[21961]: ).start()
Jan 11 05:40:41 raspberrypi hass[21961]: NameError: name 'threading' is not defined
Jan 11 05:40:41 raspberrypi hass[21961]: INFO:homeassistant.core:Bus:Handling <Event call_service[L]: domain=persistent_notification, service_call_id=3052330224-1, service_data=message=The following components and platforms could not be set up:
Jan 11 05:40:41 raspberrypi hass[21961]: * [insteon-hub](https://home-assistant.io/components/insteon_hub/)

[craigjmidwinter]

@natefanaro - Ah, sorry. Yeah, it's confusing. That's the documentation for insteon hub (cloud), Documentation for insteon_local hasn't been merged in yet by the looks of things. Your conf for insteon local will look something like this:

insteon_local:
  host: !secret insteon_host
  username: !secret insteon_user
  password: !secret insteon_password

light:
  - platform: insteon_local

switch:
  - platform: insteon_local

[balloob]

I'm going to close this issue as we have a local Insteon component now and the cloud Insteon component is almost ready to be merged again.

[broux2]

Thanks for the work on these insteon components. Do we have any idea on when we may see the local and cloud components in the public release?