barrygordon

ross, ". . . I did a fresh reboot (still using my edited rc.local) and ran the sudo ps -ef | grep java and got the following results: pi 1537 1526 0 13:57 pts/0 00:00:00 grep --color=auto java Indicates that Java has started, but none of the emulators. Using WINSCP make a copy of your rc.local file as a windows text file and email it to me at barry@the-gordons.net. There has got to be some thing wrong with it that we are not seeing. I am assuming that you are running Java 8. to check your java version type 'java -version' (without the quotes) into a terminal window. I get: java version "1.8.0" Java SE Runtime Environment (build 1.8.0-b132) Java HotSpot Client VM (build 25.0-b70, mixed mode) I have seen the same thing if I do the ps -ef | grep Java too soon after the reboot. The emulators need time to start, however I do not think that is your problem. It's got to be the rc.local file. Barry

kck, Have you tried the new version of the configuration system which handles the spoken field in the notes item of an ISY device. Let me know what you think.

Ross, regarding your issues: The logs and data sub directories must exist since they are in the path to the file you name to hold the data base (/home/pi/echobridge/data/device81.db) and the path for any messages or log info (/home/pi/echobridge/logs/log81.txt ) output by the Bridge. Both of these directories may initially be empty, but they must exist. If either of these sub directories are missing the HA Bridge program will abort. Note that I use database names and log path names that end in a number. This is because I run 4 emulators so the data base files are data81.db, data82.db, data83.db, and data84,db. Similarly for the log files. To see what is running i type 'sudo ps -ef | grep java' (without the quotes) into a terminal window. This should have a line for each instance running and one for Java itself. The line will basically be what was used to start the instance of the HA Bridge. The database file (e.g. data81.db) is a text file containing a JSON formatted string as an array of objects. JSON format is very popular and well documented at JSON.org. It is only read when the bridge is started. it looks something like '[<deviceentry>, <deviceentry> . . . ]' The log entry will contain some startup information and any debugging messages if debugging is turned on. It will typically look like: [main] INFO com.bwssystems.HABridge.HABridge - HA Bridge (v1.2.1) starting setup.... [main] INFO com.bwssystems.harmony.HarmonyServer - setup initiated (development mode).... [main] INFO com.bwssystems.HABridge.devicemanagmeent.DeviceResource - HABridge device management service started.... [main] INFO com.bwssystems.HABridge.hue.HueMulator - Hue emulator service started.... [main] INFO com.bwssystems.HABridge.upnp.UpnpSettingsResource - Hue description service started.... 2015-12-05 17:26:00.346:INFO::Thread-0: Logging initialized @22711ms [Thread-0] INFO spark.webserver.JettySparkServer - == Spark has ignited ... [Thread-0] INFO spark.webserver.JettySparkServer - >> Listening on 0.0.0.0:8081 2015-12-05 17:26:00.996:INFO:oejs.Server:Thread-0: jetty-9.3.z-SNAPSHOT 2015-12-05 17:26:01.269:INFO:oejs.ServerConnector:Thread-0: Started ServerConnector@5781ac{HTTP/1.1,[http/1.1]}{0.0.0.0:8081} 2015-12-05 17:26:01.272:INFO:oejs.Server:Thread-0: Started @23656ms [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - UPNP Discovery Listener starting.... [main] INFO com.bwssystems.HABridge.upnp.UpnpListener - UPNP Discovery Listener running and ready.... I find that using WINSCP makes my life very simple. I open a WINSCP session on my PC and log into the RPi as userid=root with a password=root. I can now examine and edit any thing on the RPi with no hassle. WINSCP will remember any session you define. I never physically deal with the RPi as it runs headless. I use tightVNC on the RPi which allows me to use VNC on any PC or on my iPads to act as keyboard/mouse for an RPi. I generally just use the VNC capability to reboot the RPi Hope that helps. Please document what finally resolves your issue so others may benefit.

You can probably start at about page 16.

I am not at all familiar with the software you are running. Most people are running the emulator from BWS Systems (bwssystems.com). the current version is 1.2.1. The configuration program for the emulator is at my site www.the-gordons.net and can be downloaded from there. Most people run their emulator on a Raspberry Pi, but all that is needed is a machine running Java 8 I can not help you with what you are using.

I have just posted a new version (5.0.40) of the configuration program for the HA Bridge on my web site (www.the-gordons.net). The major change is the ability to process the 'Spoken' entry of an ISY devices 'Notes' dialog. A change to the ini file is required for this feature to be made operable so backwards compatibility is assured. If the ini file is not changed the program works as before, If the ini file is changed but no device has a 'Spoken' entry then the program works as before for that device. If the ini file is changed and a device has a non-blank spoken field in the ISY; then the entry specifies which name, Spoken or Device, will be displayed ehrn that device is selected as the device to be edited in the device editor pane. A button is provided to switch between the two names in this case. As always the friendly name can be manually changed to what ever is desired.

The major change to enable that ELK capability was the inclusion of ${intensity.math(f(x)}. That was included by BWS Systems a month or so ago at the request of I believe BlueMan2. What's nice about small independent developers is that they are generally very responsive. There are some Amazon issues with the discovery of device which IMHO have always been there. At the current time I run 4 instances of the emulator and all my devices are found by the Echo with 2-3 tries. Since I do not add devices too often it is a non-issue for me. I almost never change the settings on my Z-Wave thermostats so I have never implemented voice control for them.

kck, Got it. Needed to update the console. Expect a new version of AWS_Config that handles the Spoken Field of the Notes Item this weekend. I will post here when it available.

rizast, What does your network look like with regard to IP address for the Emulator and the Echo. I suspect a network issue. Are all firewalls off and are uPNP searches enabled ? It would help if you told us what configuration of the Hue emulator you are running and what you are using as the configuration (mapper) program, If you are running my Configuration system, then send me the log file of the last time you ran it. With regard to the emaulator, turn on the debug option and send that log. You will need to do a fresh start after turning the debug option on.

Where does one get that UI? When I upgraded I just manually upgraded from the 4.3.26 Firmware. Point me to the matching UI and I should be good.

kck, I do not see the Spoken field on the Notes dialog. I know I used to. I am running firmware 4.3.26 and UI 4.2.30. What UI are you running?

jackal, What you say is true. but if you want to eliminate the "... tell IZZY" for simple commands then you run both. I am Assuming that the new skill will require some sort of a fee. I have heard rumored a $50 two year subscription fee for the UDI skill, but that is just a rumor. Amazon charges a usage fee, but for a single developer doing testing (aka me) it is free.

It should be able to run bothe the Emulator and the new UDI skill. We will have to wait to be sure. Hopefully the new skill will handle things like Thermostats, Fanlincs, and other non on/off/dim devices in a much cleaner method. My plan is to use both; Native for simple lighting control tasks and IZZY for non lighting tasks.

A raspberry Pi uses a trivial amount of power. You can mount it on a wall or hide it on a shelf. All my Raspberry Pi's are wired units for their Ethernet connections, no monitors, no keyboards.

It is worthwhile to read the entire thread just to gain context. I joined the thread at page 16 post #319. The HUE Emualtor, actually called the HA Bridge, is developed by BWS Systems (bwssystens.com). I do believe most ISY users are using that as their emulator with the front end I wrote as their configuration tool. The emulator runs on any machine that runs Java 8, and the configuration system is a Windows (7) program. The emulator has to run 24/7 and a lot of people are running it on a Raspberry Pi 2 B with no monitor and no keyboard (headless) using tightVNC as the remote desktop tool. As a piece of information VNC (latest version) on the iPad will connect to tightVNC on the Pi with no issue. The emulator is needed at this time since there is not a native skill provided by amazon for the ISY. Amazon does provide a native skill for the Philips HUE bridge that is limited in that it was made for lights not thermostats, security systems etc. BWSSystems developed a program that follows the API for the HUE Bridge and therefore looks to the Amazon cloud as a HUE Bridge. UDI is developing a skill for the Echo/ISY pairing. It will not be a native skill, only amazon can develop a native skill. Since it will not be a native skill but a named skill. Think of Alexa as a supervisor with a bunch of named workers that can be called on to perform tasks that Alexa can not do by herself (natively). This changes the spoken phrase to the Echo slightly: Alexa, tell <workerName> to . . . Alexa, ask <workerName> what . . . My understanding is that the worker name for the ISY non-native skill will by "Izzy" so the speech required would be something like: "Alexa, tell Izzy to turn off the kitchen lights" The above is just a guess on my part as I have not been in discussion with Michel at UDI A non-native skill, or as I call it a worker, is not difficult to write. It is time consuming however as all variants of what a user might say need to be covered with appropriate verbal feedback if not understood. I am registered with Amazon as a developer and can write my own non-native skill to handle the oddball things in my home that are not controlled by the ISY e.g. the Theater, the Pool, etc. I first want to see what UDI comes up with.

imagamejunky, I use the following commands for my 70 some odd lights/scenes 'Alexa, turn on the <friendlyName>' 'Alexa, turn off the <friendlyName>' 'Alexa, dim the <friendlyname> to fifty percent' The friendly name is either a device name or a scene name e.g. "Kitchen Lights", "Klitchen Area" When an area has several different lighting systems, e.g. the Kitchen, (Main lights, Peninsula Lights, Pantry lights, Counter lights); I define an ISY scene and name it appropriately (e.g. Kitchen Area) to handle all the lights in that area. Bear in mind you can not dynamically change the brightness of a scene.

kck, I started looking at the 'Spoken Name' property. I am running ISY 4.3.26. The 'Spoken Name' property used to be in the notes associated with a device. It is no longer there. The notes property now has; 'is Load', 'Location' and 'Description'. I could use location, but that might be confusing for the 'Spoken Name'. Has the 'Spoken Name been' removed by the UDI team or moved somewhere?. The code to add the spoken name as a choice for friendly name is trivial. It will be in a drop down list if it exists with an option as to which is the default friendly name; the spoken name or the device name. IIRC the 'Spoken Name' was originally set up for the ELK system for announcements.

I have my router (MikroTek) reserve that IP address based on MAC address so there does not seem to be an issue. I an't say enough about the MikroTek router. Best $50 I ever spent.

kevin, If you want me to show spoken name I can do that. I actually wrote the code originally to get the spoken name. And i do have it along with the description. How would you like to see it presented or how do you plane to use it - As the friendly name (the one Alexa recognizes) ?. The HA Bridger Data base (<filename>.db) is the entire configuration as saved by the HA Bridge. It is a JSON string. You can save that at any time on the Pi. Just remember the HA Bridge only reads the .db file when starts. I was going to provide a save restore, but eventually decided not to. If you notice in what i posted a little earlier in this thread I name the HA-Bridge "current.jar" so I don't have to change the rc.local as I change versions.

A couple of things. I have never said that what I produced was better, others have so stated. "Better" is a subjective evaluation. I personally have never used any any other methodology then the BWS Systems Hue Bridge, and the configuration system I wrote. I wrote the configuration program because the HUE bridge did not query the configuration of the ISY and required a lot of typing. I suspect (??) there are other front end systems to the HUE Bridge that will do similar things. Most of the steps in what jackal posted are one time steps to set the system up. Steps 3d and 4b need to be repeated only when adding new devices to the ISY that you want to control. The issue with having to ask the Echo to discover devices multiple times is being looked into by both Amazon and BWS Systems. At one time early in the game one needed to ask the Echo to do discovery only once and all devices were found. The purpose of the rc.local segment: _IP=$(hostname -I) || true if [ "$_IP" ]; then printf "My IP address is %s\n" "$_IP" fi is to capture the IP address of the Raspberry Pi as a variable ($_IP) so that it can be used on the start up lines further don in the rc.local file. ergo instead of: -Dupnp.config.address=192.168.1.99 one can write: -Dupnp.config.address=$_IP I also run 4 instances of the HUE Bridge JAR but I only use version 1.1.0. The rc.local file I use is: #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. echo "Running the RC.local Bash script" # Print the IP address _IP=$(hostname -I) || true if [ "$_IP" ]; then printf "My IP address is %s\n" "$_IP" fi #The following is for multiple emulators on the same machine #echo "Starting the Echo Bridge Emulators" nohup java -jar -Dvera.address=192.168.1.229 -Dupnp.config.address=$_IP -Dserver.port=8081 -Dupnp.response.port=50001 -Dupnp.device.db=/home/pi/echobridge/data/device81.db -Ddev.mode=true /home/pi/echobridge/current.jar > /home/pi/echobridge/logs/log81.txt 2>&1 & nohup java -jar -Dvera.address=192.168.1.229 -Dupnp.config.address=$_IP -Dserver.port=8082 -Dupnp.response.port=50002 -Dupnp.device.db=/home/pi/echobridge/data/device82.db -Ddev.mode=true /home/pi/echobridge/current.jar > /home/pi/echobridge/logs/log82.txt 2>&1 & nohup java -jar -Dvera.address=192.168.1.229 -Dupnp.config.address=$_IP -Dserver.port=8083 -Dupnp.response.port=50003 -Dupnp.device.db=/home/pi/echobridge/data/device83.db -Ddev.mode=true /home/pi/echobridge/current.jar > /home/pi/echobridge/logs/log83.txt 2>&1 & nohup java -jar -Dvera.address=192.168.1.229 -Dupnp.config.address=$_IP -Dserver.port=8084 -Dupnp.response.port=50004 -Dupnp.device.db=/home/pi/echobridge/data/device84.db -Ddev.mode=true -Dharmony.address=10.0.0.1 -Dharmony.user=noone -Dharmony.pwd=password -Dorg.slf4j.simpleLogger.defaultLogLevel=DEBUG /home/pi/echobridge/current.jar > /home/pi/echobridge/logs/log84.txt 2>&1 & echo "Starting the tightvncserver" /etc/init.d/tightvncserver start echo "The RC.local Bash script has completed" exit 0 The above script is based on a directory structure of /home/pi/echobridge where the Jar is and also two sub-directories data (/home/pi/echobridge/data) and logs (/home/pi/echobridge/logs. Each instance of the Hue Bridge will use a different name when it writes the data base or logs information into the appropriate directories. Only instance 4 is used for debugging (by me) so it has an extra parameter on the startup line to turn debugging on in the HA Bridge. The Configuration program will turn on extensive debugging based upon a parameter in the ini file and will put the information into a text file AWS_Config.log in the same directory as the AWS_Config.exe.

I know Michel reads these threads and and is busy involved in developing the skill for the ISY. I am sure he follows this one. If he feels it is advantageous to start a new forum section devoted to speech control of the ISY I am sure he will do so. I am sure that the new skill will be better than trying to emulate the HUE system, even with the overhead of having to add the two words as in 'Alexa, tell Izzy to . . . " If any of you want to contact Michel feel free to do so jackal, You should post your setup. stusviews, My point exactly. I am currently playing around with a ceiling mount for the Echo based on the premise, 'Nobody looks up'. It starts with a nice 8" basswood disk with a nice routed outer edge, and a hole drilled in the center that is a jam fit for the Echo. My home is no issue as it is one story with full attic access so adding a receptacle for power is not an issue for me, It might be in the lower floor of a multistory dwelling. Ceilings in my home are 12 feet in the Great Room and 10 feet everywhere else.

'Better' is an interesting word. It depends on what you are looking for. The configuration system I wrote runs under windows seven and is well documented. It is available at my web site www.the-gordons.net. If it doesn't meet your needs, don't use it, just uninstall it.

Read the 40 pages. It will give you a better appreciation as to what has been going on.

This is documented in the docs associated with the release. Basically you send an http command including user id and password to the appropriate port on the ISY with the payload being the REST command. You may want to take this question over to the question/How To area in the forum where an individual more knowledgeable on ISY operations might be able to assist you. I use raw TCP/IP and do not interface to the ISY using a browser so I do not want to give you incorrect information.

The REST interface I am referring to is merely the protocol used on the ISY994 to communicate with it over TCP/IP. I just don't know if the older model ISY has that same protocol built into it. It is standard on the ISY994 and not an optional module. The Rest protocol allows you to submit requests for information and commands to the ISY using TCP/IP. There is an ISY that handles IR, I think it is the ISY994IR I have no idea what the interface to the ISY is through the Admin console.