kck

One of the things I did when I installed a bunch of Insteon switches during a master bedroom remodel was to create a bedside consoles by mounting an 8 key keypad in a box for each of our nightstands that can control all the lighting in the bedroom and do things like prep the bathroom (heat floor and towels, make sure the hot water recirc is running, etc.). This had incredible WAF scores - my wife loves not having to get up to do this stuff. When I got a RPi to run the Echo bridge stuff I thought it might actually make a much more functional bedside console for about the cost of a Keypadlinc. So I got an Adafruit 3.5" touchscreen display for it and have build a soft console that mimics everything that the existing keypad does but allows for an arbitrary number of screens as well as different types of screens. It is about the same cost as the KPL since it is just a RPi, the $45 PiTFT screen, a case, and a $10 wireless adapter. I think it should actually work fine with a Pi Zero and the cheaper 2.8" screen which really would make it the same cost (and the code should self configure to the smaller screen though I haven't tested that). Currently it supports on/off keys (the keys change appearance mimicking the KPL LED), and keys that run programs (e.g., I have one that sets up the bathroom). Key display tracks status changes from other switches by watching the ISY event stream (i.e., it behaves like a key on a KPL would when the key is a responder to a scene). It self configures the key layout for the number of keys on the screen (i.e., it isn't restricted to 8 - anything from 1 to 25 keys will be displayed sensibly). It also has a clock screen with a configurable day/date etc. appearance. Pretty much all colors (background, keys, characters, etc.) are configurable from the configuration file, as is a homescreen to which the display returns after a user set time period and a time to dim the screen. I plan to add some other screens that I'd like such as a weather screen and a thermostat screen. The entire project is coded in Python and adding a screen type basically amounts to coding a subclass of a defined Python screen class to do the setup from the configuration file and the actual display when called upon. The only hardware issue I have at the moment is that I'd like to find or fabricate a screen bezel to make the unit appear a bit more "finished". The code is up CORRECTION: code is on GitHub.com/kevinkahn/softconsole now on bitbucket at https://github.com/kevinkahn/softconsole in case anyone would like to use any of it as is or as the base for their own unit. Just thought that I'd share this given all the helpful stuff I've learned from others here. Within reason I'm happy to answer questions regarding the project. For a few pictures of this see: https://1drv.ms/u/s!AmUpYkWiYac5g907yF7tyubLcd5uiw?e=QXazzA

I'd like to second Barry's comments above that the existing emulator plus his bridge provides a quite reliable, configurable, and robust solution. It strikes me that what would really be nice is if we could get Amazon to broaden the vocabulary of their connected home built in skill and also generalize a bit the api they are using with the Hue, Insteon Hub, etc. One could pretty easily define a general home control node api as a generalization of any of these and publish it to all as the way to allow additional folks to build home resident bridges. This would eliminate any need for a skill living in the cloud, reduce the overhead on both Amazon and 3rd parties (UDI, Insteon, . . .) in supporting Echo integration, and generally create a well defined interface that the entire industry could probably use going forward. If I were still at my old job I'd have opened discussions about this with all the players and try to create a forum for this (perhaps there is already one I'm not aware of). We did this many times over the past few decades with great results (USB, Upnp, WiFi among the best known examples of it). Right now without a standardized meeting point you get stuff that is too specific to either the speech engine (Echo versus Siri or Cortana or OK Google) or too specific to the home controller (UDI, Hue, . . .)

Not using this yet as I am pretty happy with the Hue bridge solution but I suggest, based on the comments here, that you rethink your distribution of utterances for unusual requests. I would wager that relatively few people run multiple ISYs and yet you have a lot of phrases aimed at selecting and querying for that case. Many of the phrases aimed at these activities are similar to phrases aimed at the 98% cases of dealing with devices in one house attached to one ISY. This will inevitably cause conflict/interference with these much more common utterances. I think you'd be better advised to be very narrow in the phrases that you allow for unusual actions - say only accept "select ISY" or something like that for the multiple ISY case. This should mean that you don't have folks dealing with some of the confusions like switch izzy versus switch light. The usability of this sort of spoken interface is impacted by all the other phrases that are meaningful and not just the ones aimed at what you are trying to do. Anyway - just a thought.

Hadn't realized that was a text file - that should work fine. Thanks!

Different question for folks running this config/bridge system. Any ideas on eas(ier) ways to deal with changing the ISY password info? At the moment all I can think of is deleting everything from the bridges and recreating it all which is certainly doable with the excellent tool Barry created but annoying nonetheless. Issue is that every URL in the bridge has the username/password baked in. In retrospect it would have probably been nice to have had the bridge have a substitutable string for the authentication. Having those user/password urls flying around regularly on the network actually ups the need to periodically think about resetting them. Every time the Echo turns a light on the password goes up on the WLAN in the clear.

Barry, Noticed that you had a new update (5.0.50) which I assumed was for scene spoken names so I installed that. Scene spoken names seem to work fine. Minor (I think) item is that you had been categorizing the device type as a "Scene" in the earlier version but not it looks like you just leave that field blank. Fine with me unless that is important for some internal reason but I thought I'd point it out. Also, when installing the new version over the old one you don't seem to have the file dates right. The new .exe file (which presumably you generated today) installs on my system with a date of 11/8/2015 which causes the installer to think its an older version. There are some older version of dlls in your package for which keeping the up to date ones seems the right answer but clearly you want the new exe so you have to look carefully at the various installer messages to make sure you get the right files kept/replaced. By the way, after a reboot of Win10 your package is again finding my bridges via Upnp. This wasn't the first reboot in my saga though so not sure why it fixed things this time. For the moment the Echo and your program both seem to find the bridges correctly and I have the RPi back on the WLAN. Fingers crossed. Thanks again, Kevin

Those single quote marks are "line ignores". So lines 1, 3, and 4 are comments if that is actually what is in your config file.

apnar, Thanks for the udp6 info. I hadn't seen that either. Also thanks for the nice rc.local script - much cleaner and easier to maintain. Further playing on my end last night saw continued weirdness that makes me think it is some larger network connectivity issue. I switched my RPi over to wired and the (for a short while) Barry's configurator could search discover it. So could the echo. Now though Barry's program (on a wired Win10 box) again doesn't find it via discovery. Strangely the echo (on wireless of course) does still. So it seems that something is messing with the upnp discovery traffic on my larger network. Stumped but at least for the moment Echo control is back. When I get a change I will probably turn on debugging in the bridge and see if anything looks odd there with the new setup. I really need to eventually get the RPi back on the wireless net for location reasons. Sigh. Feels like the sort of software debugging I last did about 25 years ago!

Barry, Figured that maybe you hadn't realized that scenes had spoken names also. At the moment I am just stumped (and I am a pretty good networks guy since in a past life I developed this sort of stuff including some of the early UPnP specs). I've been running your stuff on Win10 from the start and the bridges (and the emulator before that) on the RPi. I didn't think I changed anything when I upgraded to your recent version today. In thinking back, I think the upnp discovery was just gone when I started. I had run your previous version without explicit IP address for the bridge so I know it was discovering upnp items at that point. Now it just isn't. I've turned on all the logging in the BWS code and nothing really looks amiss. What I see on my RPi when I do a netstat -a is that there are 2 entries (I run 2 bridges) for listeners on port 1900 that show as "udp6". I see no listeners for port 1900 that show udp. If I look at network devices on my Win10 system I don't see the bridges and I would have thought, but can't be sure, that they would appear there if they were being discovered (my Sonos devices appear there). I also have a little free upnp discovery app on the Win system and it also doesn't see the bridges. So it looks to me like there is something breaking in getting upnp set up. It may well be something I am doing wrong but I just don't see it. My suspicion is that there is some sort of subtle interaction between some particular aspect of some RPi configurations and the bridge code that is causing all this but I sure don't see what it could be.

Barry, Loaded up your new version. Spoken names work fine for devices. They don't seem to work for scenes though. Unfortunately my bridges seem to have developed the problem other folks are seeing and are not longer appearing as Upnp devices on my network. I can't think of anything I changed. They start fine and so long as I give your utility the actual addresses of the bridges you can configure them fine. Your utility won't find them though by searching and neither with my echo any longer. They respond fine on the 8081 and 8082 ports (I'm running 2 bridges) but for whatever reason don't seem to be responding to upnp discovery. I turned on upnp trace in the bridges and they seem to set themselves up or at least don't report any errors. However, none of Echo, your tool, nor a small Upnp Discovery app seem to see the bridges. There is something really strange going on here. Edit to add: It appears that the bridges are listening on port 1900 for udp6 (ipV6) packets but not for ipV4 udp packets. I think it should be listening on both. I get this from a netstat on the running RPi. This would suggest that something is awry in the bridge code. You seem to have a contact with the guy who has been developing that - can you pass this along to him? I'm happy to do it myself or to do further debugging for him if needed. Kevin

Also - if the bridges seemed to work when started manually but then fail when in the rc.local you might want to make sure that they are not running into a problem related to starting before the network is up. I had a version of this problem I described up thread where I was using the programmatic way of getting the local IP address to set in the command line and this was executing before the boot time DHCP exchange had completed getting an address for the RPi. There may be other similar issues with the bridge trying to start too soon and blowing up even if you are using a hard coded local IP address. You might try just delaying the startup for the bridges. What I did to solve my issue was to put the actual bridge start commands in a separate script that starts with a sleep 20 and then run that script from the rc.local (ending with an & so that the rc.local doesn't have to wait - not sure if that might delay other start up things). Just some other things to look at if it seems that stuff starts manually but not automatically.

Are the bridges not starting or just not responding to uPnP? If you aren't sure do a "ps aux | fgrep jar" and see what is actually running. You should see an entry for each bridge process (plus one for the ps command itself). If you don't then your problem is that the bridges either aren't starting or failing. If you see the processes then they are running but not responding correctly to the Upnp traffic.

I'm running 4.3.26 UI as well. I think in general UDI suggests you always run the same versions of the firmware and UI or you can see mismatches like you are seeing. Kevin

@rizast Are you sure that you have correctly set the uPnP config address on the invocation line for the jar? Per my experience if this doesn't get set correctly then the Echo won't find the bridge and hence won't find any devices.

Barry, I'm confused on the Spoken field. I am also running 4.3.26 and I see it. When I right click on a device or scene the popup has a Notes item and when I click that I get a box with an IsLoad check box and fields for Location, Spoken, and Notes. You don't see that? Kevin

Missed the comment about current.jar. Same thought - comes from too many years as a developer. I was thinking that the spoken name field from ISY would populate the Friendly Name if it was not blank and otherwise use what you do now. It isn't a really big deal - just that since Michel and friends have provided it, it would be nice to maintain all the info there if possible. By the way - to the larger thread - I just pulled out a few more of my few hairs on an (as always after the fact) obvious issue in starting the bridge. I was using the IP address variable so that if I were to move the Pi by changing my reserved DHCP addresses it would just continue to work. Had erratic results with whether the Echo could see my devices. Eventually I looked carefully at the bridge invocation from ps. Turned out that depending upon timing, sometimes the rc.local ran before the Pi had finished getting its IP address from the DHCP server and so the address field on the invocation was blank. Of course if I ran the same script to debug it, it always worked since by then the system had been up for a while. So if anyone sees the situation where sometime the bridge is invisible to the Echo and sometimes not you might want to add a (relatively long) delay with a sleep in the script before the bridges get started.

Barry, Finally got around to beginning to set up stuff with the BWS bridge and your configuration tool. I had a limited setup running since very early on using the old emulator and semi-manual configuration which was too fragile to touch. Nice job with your front end. One quick question/verification. You do not read the "spoken" property from the ISY with any option - correct? It would be nice to have the spoken names in one place but it isn't a big deal to enter them via your front end. But I just wanted to make sure in case I was just missing something. The only downside of the current setup is that I always like to have a "scriptable" way to recreate entire configurations in case I ever need to reproduce everything and if I am renaming devices/scenes/programs with the Friendly Name field I can't see any way to capture that such that I could recreate things without manually doing that all over. Am I missing something? Again - thanks for a great piece of work. Kevin P.S. I hate editing things like rc.local needlessly so a suggestion to folks who use this setup. Have your rc.local start the bridge with a name like ha-bridge-latest.jar or some such and in your bridge directory have a link from the version you download to that name. That way when you download a new version of the bridge you can keep its version name (which is convenient) and just relink it as the "latest" name and not touch the rc.local.

When we remodeled the bathroom and put in the floor heat the contractor wanted to put in a modern "smart" thermostat but I had him put in an old style simple temperature sensing one instead. Then I wired an on/off switch into the electrical feed to that. When a program or switch turns on that Insteon on/off the floor heat thermostat and system get power and all the thermostat does is keep the floor from overheating by turning off the floor heat if it hits the temperature set on the dial. Very simple setup. I did the same thing with the towel heat feed so it too can be turned on/off via program. I have ISY timers in programs that start whenever one of these heat systems is switched on to limit the total time that they stay on so we don't have to remember to turn them off.

You can call programs from Echo - I do it now. You just need the url for the on or off to be one that invokes a program. My 2nd most used Echo call is to run a progam that gets the bathroom ready for a shower - makes sure the hot water recirc is running, turns on floor and towel heaters, lights if needed. I walk into the house after a hot round of golf and tell Alexa to turn the bathroom on.

I do wish they would expand the vocabulary in their API a bit. Things like "open" and "close" e.g. for doors or "lock" and "unlock" for locks. I'm sure there are some others. Seems like Amazon wants to codify the way the class of HA things are controlled by Echo by limiting how much the adapter has to do and not requiring a full fledged skill, but to do that well will need a richer vocabulary in the underlying skill or folks will do their own skills anyway which will result in lots of nearly identical skills which seems to be what Amazon doesn't want.

How are you planning to make it available? Open sourcing via github or otherwise. It could be a good start for a broader Echo service with more flexible intents etc. as folks look to add stuff that requires requests other than on/off.

By the way - it is pretty easy to add program invocations as a result of a name/on or name/off request to Echo. I used the manual part of the configuration to add execution of some programs (via runThen and runElse) and the result is really convenient access to some things that can't be handled by scenes. If you can pick good names then the Echo invocation string even sounds reasonable. E.g., I have a program that preps the master bath by turning on floor heat, towel heat, hot water recirc, lights, etc. (very high WAF!) and now we can just say "Alexa turn on bathroom" to get things going.

@kgividen I just got back home and had a chance to try the configurator again after the issue I was having last week. It turns out that, at least on Windows, the --disable-web-security switch isn't effective unless all instances of Chrome are closed when it is invoked. Once I closed even the background Chrome from the notification area then things worked. Figured I'd let you know in case others encounter this.

Just looked (hadn't earlier). Error is: GET http://192.168.1.15/rest/nodes/ 401 (OK)(anonymous function) @ angular.js:9902sendReq @ angular.js:9703serverRequest @ angular.js:9415processQueue @ angular.js:13292(anonymous function) @ angular.js:13308Scope.$eval @ angular.js:14547Scope.$digest @ angular.js:14363Scope.$apply @ angular.js:14652(anonymous function) @ angular.js:21678b.event.dispatch @ jquery.min.js:3v.handle @ jquery.min.js:3 configurator.html:1 XMLHttpRequest cannot load http://192.168.1.15/rest/nodes/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. The response had HTTP status code 401. I imagine it is the "No Access-Control-Allow-Origin" item. I supplied my username and password for my ISY though they don't show here. Actually, since I have already accessed the ISY from this machine it seems that the node list gets returned even without actually supplying the authentication info on the REST URL.

I tried you version. It gets the current devices in the emulator fine but doesn't seem to get anything from the ISY. I edited the js to insert my IP address and username/password but pushing the get devices button doesn't do anything. This was on an instance of Chrome launched with the no web security flag per your instructions. If I just manually reference http://usr:pwd@isyaddr/rest/nodes I get a very long listing of my nodes.