Insteon - Sonos Support via HUB II

[Teken]

Today Smartlabs has indicated formal support of the Sonos audio system via the HUB II controller the related link is here: http://www.insteon.com/sonos

 

Smartlabs will also be making dedicated audio buttons for the KPL Switch. As much as I bag on Smartlabs about various things from time to time they swing hard and swing big.

 

Congratulations to all the hard working people at Smartlabs who made this Sonos / Insteon integration possible. I am sure those with less technical skills to write code or read endless forum threads will really appreciate this simple and effective method to combine the two.

 

The vulnerable little HUB II is starting to show me and many others that you shouldn't count Smartlabs out of the Home Automation race.

 

Congratulations to Joe Dadda and his team in pushing the envelope on a $79.XX controller.

 

Well done . . .

 

News Articles: http://www.thedigitalmediazone.com/2016/01/07/insteon-adds-sonos-control/

[madcodger]

They're giving CONSUMERS what they want, and making it easy. Goodness knows I've been mad at them many times. But they are making me take another look at that little device, 'cause time is precious. I really like UDI, but I'm not trying to manage energy use in a plant somewhere and I don't code (yet, anyway). "It just works" has an appeal.

[Teken]

They're giving CONSUMERS what they want, and making it easy. Goodness knows I've been mad at them many times. But they are making me take another look at that little device, 'cause time is precious. I really like UDI, but I'm not trying to manage energy use in a plant somewhere and I don't code (yet, anyway). "It just works" has an appeal.

 

Agreed, you will never convince anyone who is a casual user that something as powerful as the ISY Series Controller is the solution. When you break it down to them they need to sit down to read and learn lots of random code and various computer languages.

 

This is probably the only reason I have kept the three HUB II's around because I could see more integration coming down the pipe that made it worth while to keep.

 

Given another related thread where HUB II user was able to integrate the ISY with little effort and conflict. This may very well be that small bridge that allows everyone to have their cake and eat it too.

 

They will have the power, capability, and flexibility of the 994 Series Controller but also have the ease of use and integration of the HUB II to allow: Apple Watch, Amazon Echo, Harmony Remote, Sonos Integration.

 

I'm calling this out right now there better be lots of new developers who are keen on taking on this whole node server / poloyglot development scheme. Because if there isn't an easy method for someone to purchase a module or prop up a 3rd party server that allows quick and easy access to the above.

 

No matter how powerful the 994 Series Controller is it will always just cater to the dedicated fanatics like you and me.

 

The motto in 2016 will be simple is sexy and it sells . . .

[madcodger]

Agreed. And the problem as I see it is that ONLY the dedicated hobbyist is sticking it out, IF they have significant free time. I've been more active lately because it's been the holidays and I forced myself to take time off. But now it's back to reality, with a growing business to run, employees, customers, family, etc...

 

Many of us like the ability to control things around our home from our phone, or via voice, or with a tablet sitting in the kitchen. But few of us have the time or skill set to manage it.

[Michel Kohanim]

I also agree. For anyone who's looking for simple command/control, ISY is not a good choice. Revolv went down the same path as did Wink and SmartThings and there's definitely a huge market for simple command and control through the cloud. UDI is not tailoring to that market and, currently, we have no plans of doing so.

 

With kind regards,

Michel

[Teken]

I also agree. For anyone who's looking for simple command/control, ISY is not a good choice. Revolv went down the same path as did Wink and SmartThings and there's definitely a huge market for simple command and control through the cloud. UDI is not tailoring to that market and, currently, we have no plans of doing so.

 

With kind regards,

Michel

 

Hello Michel,

 

I believe some of the statements made above by me and madcodger needs to be expanded upon. Firstly, the main driver was most people tend to lean toward things that are easy to do or accomplish. This has been the case for pretty much anything in life I would suspect.

 

It is only through personal experience and trial and error does anyone really move past the *simple / easy* path. Its safe to say the dozens of people a month that transition from a HUB II, Vera, name anyone. Have realized that simple and easy does not always equate to flexibility, power, and capabilities as is seen in the ISY Series Controller.

 

Now having said this, your fine company has embarked on several fronts and projects in the hopes of making this *simple / easy* approach more obtainable for the masses. Its safe to say the inclusion of the now released and in production UDI portal is stepping stone to offer more support for third party hardware and cloud hosted service integration.

 

The UDI portal could very well replace any need for a person to prop up a RPi, create network resources, etc. Simply have the UDI portal do all the heavy lifting as is apparent by the HUB II inclusion of the Sonos audio support.

 

The next key point I wanted to stress was the fact lots of these features and possibilities are not well documented or published to the general public.

 

This in itself, is in my view, one of the biggest obstacles to your fine company . . .

 

If people don't know anything about something or where to find out more information. How will this product / service ever sell to those interested in something that offers more features and capability which by extension of the other projects like the node server, polyglot, UDI Portal, which will also offer that simple / easy capability??

 

My suggestion is the following projects and services should be pinned to every forum on this site. It should state clearly the mission goal, outlook, and current progress state. As time goes by related links that happen in this site should be appended to provide continuity or offer more insight as questions are posed.

 

Often times a member will ask a question and you will chime in and offer some critical piece of information, timeline, or insight. This information is sadly scattered in thousands of forum threads and its near impossible for a casual user to find and disseminate said information from a basic search.

 

Next, what ever on line presence your company has should be used to its fullest whether that be Face Book, Twitter, You Tube, etc.

 

Followed up with someone who can take just 20-30 minutes a month and review the docked informational threads that have to do with Polyglot, Node Server, UDI Portal and update as required. Then, fire off these links to any and all technology review vendors.

 

We have all seen massive turn out for many stupid things, events, or video's which in reality should have never garnered so much attention or public awareness. 

 

Simply put if someone is tasked by your team to at least make a concerted effort once a month and relay at a high level and on a basic level to other technology sites like wired, gizmondo, tech crunch, what ever site you feel has merit. I truly believe you will reap the rewards for the effort and time invested doing so.

 

As you know word of mouth is a very powerful thing and nothing sells better than existing clients. I've spent pretty much every year touting the power of the ISY Series Controller in every forum I am a member of. Never mind in the real world where the topic comes up.

 

Its safe to say hundreds of others do the same when and where they can . . .

 

But, this in itself will not lead the charge or make that critical difference given most of us are members of the so called dedicated few . . .

 

In closing, I don't believe anyone would like to see the 994 Series Controller ever be converted into a dumb box. What should be focused upon is making the ability to add new features, capabilities, and development easier .  . . As stated above this means the most basic things like what these projects do and direct resources citing the same needs to be prominently displayed at a hands reach for all to follow.

 

I hope the above offers more insight to my thoughts and views . . . 

[Michel Kohanim]

Hi Teken,

 

Thanks so very much for the feedback and I mostly agree with the exception of the Portal: as a philosophy - and even though it makes things 10000% easier for us - we do not like the concept of the portal because it makes automation dependent on the cloud with all the ramifications that come with managing reliability, security, privacy, and data. We had to develop the portal for Echo simply because we believe that Echo (although fun) is excellent for accessibility (i.e. link a device, create a schedule, let me know when my electricity usage is x or bill for this month goes over $y, etc.). If we had any say in Echo development, we would certainly and vehemently oppose any type of cloud dependency.

 

Having said all of this, if we had massive financial backing and resources, obviously we would spend much more time on beautification and simplification (HUBification?). Alas, we are still a tightly knit/small team and thus we base our priorities on what we believe is important for "autonomous automation and energy management" and thus my comments.

 

Thanks again and with kind regards,

Michel

[Teken]

Hi Teken,

 

Thanks so very much for the feedback and I mostly agree with the exception of the Portal: as a philosophy - and even though it makes things 10000% easier for us - we do not like the concept of the portal because it makes automation dependent on the cloud with all the ramifications that come with managing reliability, security, privacy, and data. We had to develop the portal for Echo simply because we believe that Echo (although fun) is excellent for accessibility (i.e. link a device, create a schedule, let me know when my electricity usage is x or bill for this month goes over $y, etc.). If we had any say in Echo development, we would certainly and vehemently oppose any type of cloud dependency.

 

Having said all of this, if we had massive financial backing and resources, obviously we would spend much more time on beautification and simplification (HUBification?). Alas, we are still a tightly knit/small team and thus we base our priorities on what we believe is important for "autonomous automation and energy management" and thus my comments.

 

Thanks again and with kind regards,

Michel

 

Hello Michel,

 

You and I will never disagree about cloud hosted service, ever!

 

Ha . . .

 

We both have the same view and many like minded users who have tasted the cloud knows the pitfalls simply waiting to happen. But as you stated also it make some forms of integration so much easier for the general public. I would never expect your fine company to sway from the basic principles of autonomous HA control, ever . . .

 

But it should be cited and affirmed a middle ground can be found using the UDI Portal. As I recall your intention is to at some point in time to offer IFTT. This in itself will put you in the same camp as others that offer the very same.

 

In another related thread someone had offered a link to a Z-Wave door bell. The author of the review also conducted a over view of many of the HA controllers in the market which included the 994 Series Controller. The 994 Series Controller came in a close second to the Smartthings controller with a B+ rating.

 

As I continued to read the reviews by this author he continued to focus on something I find super annoying and really a none issue.

 

That was IFTT support was not present and hence why those controllers got docked a mark over all. My view is IFTT is for the stupid, lazy, inept, and is simply a fad that just won't die and go away.

 

But the simple fact is no matter how I feel about that IFTT has a place in the market and millions of people see great value in this service. If and when your company decides to offer IFTT support it will open possibilities that simply were not possible.

 

This again moves the 994 Series Controller into the more *Simple & Easy* category all by itself. At the same time in no way does it make the box dumber but simply offers more solutions to those who need a point and shoot approach. Yet will always have the tremendous power lurking under the hood when and if required.

 

Again, the next big fad is the pervasive use of Sonos audio . . .

 

I can assure you if your company and team dedicate themselves to offer some kind of cloud bridge that does all of the heavy lifting for the end user. This will help you sell more products and services which then by extension will allow you to have more resources to work on other projects.

 

I can only speak for myself as an outside observer and would like to think I have a good pulse of the market and what most people want. As you're probably quite aware I wear my heart on my sleeve and often times write the same way as I relay my thoughts in writings here and other sites.

 

So you know when I say the above has legs its worth considering . . .

 

Thank You!

[Michel Kohanim]

Hi Teken,

 

IFTTT is yet another one of those cloud services that we will support using the ISY Portal (albeit quite reluctantly as it moves logic to the cloud).

 

As far as Sonos, I agree!

 

Last night, I asked Echo to play some music and since I have recently started looking into audio distribution system for our home (Sonos, Nuvo, Russuound), I wondered whether or not Amazon would ever get into distributed audio. For my purposes, the only thing missing is audio zones since all I want is the ability to play radio, music, playlists and then choose where each is played (or all play the same thing) ... I guess I will wait a few more months!

 

With kind regards,

Michel

[Teken]

Hi Teken,

 

IFTTT is yet another one of those cloud services that we will support using the ISY Portal (albeit quite reluctantly as it moves logic to the cloud).

 

As far as Sonos, I agree!

 

Last night, I asked Echo to play some music and since I have recently started looking into audio distribution system for our home (Sonos, Nuvo, Russuound), I wondered whether or not Amazon would ever get into distributed audio. For my purposes, the only thing missing is audio zones since all I want is the ability to play radio, music, playlists and then choose where each is played (or all play the same thing) ... I guess I will wait a few more months!

 

With kind regards,

Michel

 

Hello Michel,

 

I know lots of this is very much in flux but are you open to the idea of supporting Sonos via the UDI Portal at some time? From a marketing stand point being able to say on the sales page.

 

The ISY994 Series Controller: Works with Amazon Echo, Sonos, IFTT

 

 

I know from speaking to lots of random people just seeing this in the marketing literature would make people take a serious look at a product. 

 

EDIT: I also wanted to call out and affirm that I too like to see as much native functionality via the controller before a cloud service is tasked to do the same. Ideally your company should offer a zip file that can be loaded into the controller which includes all of the basic network resource attributes.

 

All the user has to do is change the IP / user name  / password should it be present. I do realize the original author has done the very same. But this really needs to be done in a formal fashion by UDI and be included in any new firmware release so its a tab that can be enabled and fine tuned. 

[Michel Kohanim]

Hi Teken,

 

Sonos, unlike Echo, is accessible locally. So, whatever we do to make the integration easier should be done locally. There are already network resources available for Sonos, and work very well, so all we have to do is to make the configuration a little easier. It does not make sense to go through the cloud.

 

With kind regards,

Michel

[Teken]

Hi Teken,

 

Sonos, unlike Echo, is accessible locally. So, whatever we do to make the integration easier should be done locally. There are already network resources available for Sonos, and work very well, so all we have to do is to make the configuration a little easier. It does not make sense to go through the cloud.

 

With kind regards,

Michel

 

Hello Michel,

 

100% agree and I had made a edit before your reply. What ever can be done natively for sure and if its something that can be included into the firmware and the user simply needs to make the final configuration is perfect!

 

I thank you so very much . . .

[MWareman]

As Michel said, the API for Sonos is local. It would be awesome if there was a native (premium?) module on ISY for it (like the Elk module...). Control and status must stay local! Let's reward Sonos for forward thinking their API.

 

If you hook Sonos up to a Hub II, the Hub's API is cloud based. Fine for Alexa to control it, if that's what you want, but I wouldn't want to be stuck not able to control my Sonos if the Internet is down.

 

Personally, I home Alexa will eventually be able to natively talk to Sonos on lan.

[mwester]

I can't help but note that given the price point of a Sonos installation, the module that MWareman mentions above might be able to command a fairly premium price (assuming it had a reasonable set of features).

 

I've looked at what a node server via Polyglot might be able to do, and while it's valuable, the UI associated with a node is not quite rich enough - so a full module would probably be better.

[Teken]

I don't personally have a Sonos device so besides the obvious what are some of the API possibilities a user can expect to have and initiate?

 

- Play, Pause, Stop, Next, Back, Skip, Favorites, Channels, Memory, Preset?

- I understand that you can invoke the system to go to a Internet radio but that is part of the favorites, correct?

- Changing input from Aux, Radio, Line, etc

 

- Is there access to where you send the music too? like if you have four speakers can you tell the system to send Judas Priest to speaker 1, Mickey Mouse to speaker 2, Tele Tubby to speaker 3, and Hooked on phonics to 4?

[madcodger]

Hi all,

 

I can't keep up on forum postings, but enjoy the conversation. I am the odd man out on this cloud thing. Please don't misunderstand - I PREFER local control. But if it means I need to learn to program, etc., bring on the cloud. That does sound lazy and inept to many, I am sure, but it's simply a matter of time. I have other responsibilities, so I don't program.

 

For UDI / ISY, I just want the ability to purchase modules or "plugins" that allow me to use this FANTASTIC device in an easier way, without having to write code, run a separate Rpi, etc. I like that my ISY works with my Elk. I just wish I could spend a reasonable sum with SOME company to get even more out of it, easier. I have railed on about Nest integration, etc., but now understand that UDI has no interest in being a consumer company. OK, got it. But I do wish it was easier to use, easier to find answers easily, etc. As it is, one is either in this up to one's ears, or out. There is little room for the customer that is not an industrial user or hard core hobbyist. I am not the former, and have little time to be the latter (and I think there are many of me). But I do tend to be a good customer, when the company wants me to be. In this case, I think I just own a great device that is the extent of what I can buy. Understood. Looks like those funds will end up somewhere else.

[Teken]

I believe with respect to the Sonos support via the 994 Series Controller UDI's intent is to keep it local and try to make such a feature as easy as possible to implement and deploy for the end user.

 

This could be as simple as bundling the network resource the original author has created. To UDI making it a more robust and polished *plugin module* that offers a deeper API integration not available in the base install.

 

I am open to both solutions as it offers that value to the product which is my main driver for the 994 Series Controller. Also I would like to clarify that members should never take my replies of *Inept, stupid, dumb* as inference to them or anyone else on this board.

 

Sadly, I am prone to over generalizing and not being specific enough when I reply.

 

Ha . . .

[kohai]

My two cents....

 

I think the world of linux gurus and maker communities would lend themselves well to the ISY community.  We likely already have an Rpi or two, we're used to scripting (if not programming), we understand integrating various devices, we know git/svn, etc.  I think v5 and polyglot is a big step in the right direction for technical, non-UDI people to step in start making add-on programs/modules more quickly.  Hopefully the polyglot approach makes the modules more manageable.  

 

Right now the challenge I see for newbies like me is how to start, where to find the info, etc, e.g. how to make the learning curve as short as possible.  On another thread we were talking about how, as users, can we document things on a wiki (or other ways) to help newbies bridge this gap.  There's a lot of tribal knowledge on this forum but the knowledge is buried in threads.  If we could collaboratively tap that knowledge and document, it would be easier to bridge that linux/maker community into the ISY world and they will create more modules. 

[mwester]

...On another thread we were talking about how, as users, can we document things on a wiki (or other ways) to help newbies bridge this gap.  There's a lot of tribal knowledge on this forum but the knowledge is buried in threads.  If we could collaboratively tap that knowledge and document, it would be easier to bridge that linux/maker community into the ISY world and they will create more modules.

Completely agree. I have contributed code and documentation on other wikis -- and I'd like to contribute some information on using Polyglot, and Polglot/Perl node servers, but I've not felt it to be worthwhile. Frankly, I expect that my hard work will simply get lost in a forum - it would basically be throwing away my time and effort.

 

A forum != a wiki.

 

(UDI - are you listening? Can we have a part of the wiki opened up for community authoring?)

[Teken]

Completely agree. I have contributed code and documentation on other wikis -- and I'd like to contribute some information on using Polyglot, and Polglot/Perl node servers, but I've not felt it to be worthwhile. Frankly, I expect that my hard work will simply get lost in a forum - it would basically be throwing away my time and effort.

 

A forum != a wiki.

 

(UDI - are you listening? Can we have a part of the wiki opened up for community authoring?)

 

Mwester,

 

As I understand it some members have direct access to do so already. I would engage Michel about this directly and he can offer next steps and guidance. 

[Michel Kohanim]

Hi mwester,

 

Yes, of course!

 

Please do send your request to support@universal-devices.com and we'll create you a Wiki account.

 

I am so very sorry for the lack of resources expended on Polyglot. The main issue is that the core team here is not well versed with Python and, at the same time, we don't want to make it in Java since the JVM will eat up all the memory.

 

Is everyone OK with Python (which is what the poll indicated)? If we give out the source to Polyglot, would it help?

 

With kind regards,

Michel

[kohai]

Hi mwester,

 

Yes, of course!

 

Please do send your request to support@universal-devices.com and we'll create you a Wiki account.

 

I am so very sorry for the lack of resources expended on Polyglot. The main issue is that the core team here is not well versed with Python and, at the same time, we don't want to make it in Java since the JVM will eat up all the memory.

 

Is everyone OK with Python (which is what the poll indicated)? If we give out the source to Polyglot, would it help?

 

With kind regards,

Michel

 

I think there are a bunch of people that would be interested in wiki access.  larryllix and I were talking about wiki as well.  I could see adding a bunch of program examples with explanations for newbies like me.  

[MWareman]

 

 

I think there are a bunch of people that would be interested in wiki access. larryllix and I were talking about wiki as well. I could see adding a bunch of program examples with explanations for newbies like me.

You mean Michel and I won't be the only editors anymore??

 

Wiki's really should be edited by everyone. That's the only way they get better.

[kohai]

Hi mwester,

 

Yes, of course!

 

Please do send your request to support@universal-devices.com and we'll create you a Wiki account.

 

I am so very sorry for the lack of resources expended on Polyglot. The main issue is that the core team here is not well versed with Python and, at the same time, we don't want to make it in Java since the JVM will eat up all the memory.

 

Is everyone OK with Python (which is what the poll indicated)? If we give out the source to Polyglot, would it help?

 

With kind regards,

Michel

 

Python is the language the cool kids are using (I'm not cool enough yet).  If there are resource limitations at UDI, I wonder if polyglot would get some attention from other devs if it was setup by UDI with a git repo and people could contribute.  Maybe that's a poll to query people with.  

[mwester]

<opinion>

 

Python is absolutely the correct language to use. I'm not cool enough for python either, but I'm learning.

 

Java is the wrong language for this - in addition to the memory requirements for the JVM, that language will "close off" node servers for a big segment of the folks on this forum. I feel that many folks here are capable of writing or at least of modifying an existing node server written in Python, but only a very few have the programming skills to tackle a full threaded networking Java application with the requisite development environment (eclipse, etc).

 

I like Perl - but my attempt to write a simple node server in Perl, as an example of how to do it, exposes exactly why you don't want to do this in Perl! Lack of a rich threading model is probably the biggest problem, IMO.

 

Which really leaves Python as the last language standing. It's accessible (i.e. you don't need eclipse, or jetbeans, and a full multi-hundred-MB JDK, and Java coding experience). It has a rich, standard threading model. It runs on many different platforms, should that be the direction in the future. And it's far more readable than Perl, and far easier on memory than Java.

 

So for the above reasons, IMO Python is the right answer.

 

</opinion>

 

Thanks Michel!