apnar

Barry, I'm curious why you use a VNC server? What are you doing that you need a GUI for that you can't do via text through SSH? Also, is "Sarah" a Eureka reference?

Barry, I've seen a few folks with issues with their rc.local files. Thought I'd share this rework which may reduce some issues. Nothing fancy, but changes a few things to cover issues some folks have run into including multiple instances on same port, data or log directories not existing, and starting before getting IP address from DHCP. It also moves editable fields up into variables so they don't have to be changed more than once. Anyway here it is for anyone that wants to give it a try: #!/bin/sh -e ISY_IP=192.168.1.10 NUMBER_OF_BRIDGES=3 BASE_PATH=/home/pi/echobridge JAR_FILE=${BASE_PATH}/ha-bridge-0.4.9.jar STARTING_PORT=8081 STARTING_UPNP_PORT=50001 DATA_PATH=${BASE_PATH}/data LOG_PATH=${BASE_PATH}/logs echo "Running the RC.local Bash script, Getting my IP address" # check for valid IP by seeing which IP would be used for extenral traffic IP=$(ip route get 8.8.8.8 | awk 'NR==1 {print $NF}') while [[ $IP != 192.168.* ]] do sleep 1 IP=$(ip route get 8.8.8.8 | awk 'NR==1 {print $NF}') done echo "My IP address is $IP" # Make directoris if they don't exist [ ! -d ${DATA_PATH} ] && mkdir -p ${DATA_PATH} [ ! -d ${LOG_PATH} ] && mkdir -p ${LOG_PATH} echo "Starting the Echo Bridge Emulators" for i in $(seq 1 ${NUMBER_OF_BRIDGES}) do nohup java -jar -Dvera.address=${ISY_IP} -Dupnp.config.address=${IP} -Dserver.port=${STARTING_PORT} \ -Dupnp.response.port=${STARTING_UPNP_PORT} -Dupnp.device.db=${DATA_PATH}/device_${STARTING_PORT}.db \ ${JAR_FILE} > ${LOG_PATH}/log_${STARTING_PORT}.txt 2>&1 & let STARTING_PORT=STARTING_PORT+1 let STARTING_UPNP_PORT=STARTING_UPNP_PORT+1 done #echo "Starting the tightvncserver, to handle SSL protocol for my skill 'Sarah'" #/etc/init.d/tightvncserver start echo "The RC.local Bash script has completed" exit 0

Looks cool. Does this work directly with Myq bridge or does it have to route through the chamberlain cloud?

FYI - I decided to give evilpete's code a try. I wrote up a how-to here for anyone interested: http://forum.universal-devices.com/topic/17474-how-to-receive-send-log-spoof-all-insteon-rf-traffic/

This is a guide on how to receive, send, log, spoof, etc. all Insteon RF traffic in your house. First, let me say that I can’t take credit for any of this. All the credit goes to Peter Shipley (evilpete) who did the research on the Insteon wireless protocol for his defcon presentation and then graciously released documentation and his code. This was discussed originally in this thread: http://forum.universal-devices.com/topic/16596-this-could-be-bad/. You can also see the slides from his defcon presentation here: https://github.com/evilpete/insteonrf/blob/master/Doc/insteon_defcon23.pdf There are obviously security implications to this, but at the moment I’m more interested in the functional gains that may be had. In particular the ability to actually debug Insteon issues and easily log all Insteon traffic in my house. Eventually I could see the software maturing to allow fully replacing the PLM. As the information on all the various components and software are a little spread around I figured I’d write up a step-by-step guide for those that want to get started but like me do not have any experience with RF hacking. References: insteonrf: https://github.com/evilpete/insteonrf rfcat: https://bitbucket.org/atlas0fd00m/rfcat/overview another project that used cc1111 and rfcat (covers flashing rfcat): http://v3gard.com/tag/rfcat/ What to buy: You’ll need some hardware to actually talk RF, there are a number of options evilpete’s software supports but for someone who is only going to use the hardware for working with Insteon (as opposed to broader RF hacking) the cheapest and easiest is something using the TI cc1111 chip. The chip then needs to be programed with a firmware called rfcat. If I were to do this again I would purchase a device called the Yard Stick One. It has the proper chip and is also pre-flashed with the rfcat firmware. As such it should be plug-and-play. Depending on antenna choice you’re looking at around $100-$129 for it: https://greatscottgadgets.com/yardstickone/ https://hakshop.myshopify.com/products/yard-stick-one?variant=6649135621 The other option, which I went with before finding the yard stick one, is to buy a cc1111 evaluation board from TI called the CC1111EMK868-915. You can buy it directly from TI or many other of the usual electronics distribution houses for around $75: http://www.ti.com/tool/cc1111emk868-915 The problem is that it doesn’t come with the rfcat firmware installed and you need another device to program it. I opted to get a board called the GoodFET to do the firmware flashing. It unfortunately ran another $50 which was a little pricey for a one time use device, at least I could get it Prime. If anyone wants me to flash their CC1111EMK868-915 with rfcat for them I’m happy to do so, just message me. http://goodfet.sourceforge.net/ http://smile.amazon.com/Hackaday-Goodfet42/dp/B015P8219Y/ https://www.adafruit.com/products/1279 Installing software: At this point I’ll assume you have a cc1111 device with rfcat firmware on it plugged into your computer. I did all this on a Ubuntu 14.04.3 LTS LiveCD clean boot to make sure I didn’t miss any steps. Nothing seemed too Ubuntu specific though so should work on most other Linux distros (with appropriate package manager changes). For better or for worse I did it all as root as well. # make sure you can see dongle lsusb #….mine looks like…. #…. #Bus 002 Device 006: ID 1d50:6048 OpenMoko, Inc. #…. # install base software add-apt-repository universe apt-get update apt-get install sdcc git python-usb # grab software mkdir /root/insteon cd /root/insteon wget https://bitbucket.org/atlas0fd00m/rfcat/downloads/rfcat_150225.tgz tar xvfz rfcat_150225.tgz ln -s rfcat_150225 rfcat git clone https://github.com/evilpete/insteonrf.git insteonrf # install rfcat client tools cd /root/insteon/rfcat python setup.py install Sending and receiving Insteon commands: In classic unix fashion evilpete has broken commands up into small tools that each do one major thing. There are four commands that are important: rf_reciv.py - This listens for any insteon RF traffic and outputs binary ascii to std-out rf_send.py - This takes binary ascii via std-in and broadcasts it as insteon RF traffic print_pkt.py - This takes binary ascii via std-in and outputs human readable decoded insteon packets send_comm.py - This takes command line arguments to build an insteon command and outputs binary ascii on std-out You can then use pipes and such to chain commands together. # The most basic thing is to watch all the insteon RF traffic cd /root/insteon/insteonrf ./rf_reciv.py | ./print_pkt.py #you will see something like this with each line being a decoded packet bandwidth 187500.0 0F : 52 4E 29 : 47 E7 34 : 13 00 DD crc DD 0B : 52 4E 29 : 47 E7 34 : 13 00 19 00 00 AA crc 19 07 : 52 4E 29 : 47 E7 34 : 13 00 55 00 00 AA crc 55 03 : 52 4E 29 : 47 E7 34 : 34 00 91 00 CRC B6 2B : 47 E7 34 : 52 4E 29 : 13 13 27 : 47 E7 34 : 52 4E 29 : 29 00 45 00 00 AA CRC 7F 23 : 47 E7 34 : 52 4E 29 : 13 00 00 00 CRC 81 23 : 47 E7 34 : 52 4E 29 : 13 00 81 00 crc 81 # or log the traffic to a file ./rf_reciv.py > /tmp/insteon.out # then look at it later cat /tmp/insteon.out | ./print_pkt.py # example to send an insteon command ./send_comm.py -d 163FE5 -s 132580 13 00 | ./rf_send.py For newer Insteon devices the source specified must be in its link table, so you’ll need to pick the appropriate source address (such as your PLM). I will note that the software is still pretty rough around the edges. I've had it crash out on me more than a few times from what I'm guessing is packets it doesn't quite understand yet. I hope to get some time over the holidays to put a little work into it and push my changes back over to eveilpete.

You can even lock the switches so they can't be programmed locally via options in the ISY. I lock all my devices.

If you're interested in trying to work through the issue, it sounds like an problem with your AWS_config.ini file. In particular the "Location", "ISY userid", or "ISY Password" setting in the "[uDI ISY994]" section.

Assuming you can get the Emulator to start and don't have a firewall running, all the rest of the stuff with properly formatting URLs and getting device IDs and such is wonderfully handled by barrygordon's great little configuration app. Were you having issues getting it running or configured?

Yes, I'm aware you can do things on the ISY via URL (or shall we say REST API calls). The issue is on the Echo side and how you get it to listen for a word and call the correct URL. What you're suggesting seems to be exactly number 2 I listed, using IFTTT to map echo commands to URL calls.

This still doesn't make sense though. From my understanding there is no way for the Echo and ISY to talk directly to each other. You are left with one of three options: 1) Use an emulator as a bridge running on another device in your network acting like something the Echo can talk directly to 2) use IFTTT, in which case I don't think you'd need to use different dim level approach 3) use the (hopefully approved soon) ISY skill for the Echo routing commands through ISY Portal, which again I don't think would need this different dim level approach The Hue emulator from BWS is a simple Java app, so you can run it on just about anything you may already have running 24x7 like a Pi, linux box, windows box, Mac, random NAS, etc. And as I previously mentioned you can fire off as many as you need, one per every 40 or so devices or scenes you want to control. Maybe I'm missing a forth approach where this would help.

I'm having trouble understanding why you're trying to do this in the first place? Are you just trying to get around limit on device count in the emulator? If so its much simpler to just run more emulators, you can start up as many as you need and each supports ~40 devices if I remember correctly.

Modified this slightly to add couple other 'x's that need to be adjusted for multiple emulators:

Thanks Barry. If I'm not mistaken the %20 is a space though, not a period. I also meant to say the %20 in the device ID work just fine so you can leave those as is, just need to adjust the one in the intensity byte.

Barry, Just started playing around with this stuff, great little app. I ran into a problem with getting devices to dim which I was able to work through. It appears your program (I'm using 5.0.12) creates on URLs for devices with "${intensity%20byte}". Looking at the emulator documentation (I'm using 1.0.7), it appears that it wants "${intensity.byte}" in the URL, note the period instead of %20. I changed the %20s in the in the URL to dots and it's working great. Thanks for the program!

You can temporarily set a static IP on your computer on the old range and see if you can find it. The ISY may not request new DHCP lease until old one expires, you could try power cycling it.

You can grab their super simple button: https://www.liftmaster.com/For-Homes/Accessories/Control-Panels/model-883LM If you then want something you can short you can solder to the internal button contacts of that button.

Does it require cloud connectivity to work?

I'm planning on putting in a new opener with MyQ system so have been doing a good bit of reading. I think my solution is goign to be to get an extra normal wireless remote and wire an IOlink to "press" the button on it. I also plan to hardwire power to it. Should work smoothly with no ill effects.

I reread your original post, what exactly is it you think is wrong? The only node you really need to be using is the Open node. The Closed node won't do anything in the default config of the sensor. Heartbeat just pings current state every so often so you know battery is still working.

I'd try removing the device from the ISY and adding it back using the New Insteon Device with Auto Discover. See if it adds all the nodes you're expecting.

Thanks for checking. I pulled out my backup laptop, brought it up to same versions, and I can't reproduce it there either. So I guess it's something specific with my setup. I'll see if I can track it down.

I can occasionally get one or two slides in without issue, but can reproduce the issue in a matter of seconds every time by just going to any scene and sliding a ramp rate back and forth with the mouse. Should be pretty easy for someone else with a similar config to see if it's just me or a broader issue.

So you did a hard reset and now it doesn't happen? Or does something you do after make it occur again?

Not sure exactly what you're suggesting but the communication between the ISY and PLM is not Ethernet. You could potentially use a wireless extender to connect your ISY to your home network though.

Not directly related to the above but figured I'd thread jack as title of a new thread would be almost identical. I'm running java 8 update 45 on Yosemite, I've noticed an issue with the UI hanging when trying to use a slider (such as on level or ramp rate for a scene). The little ball will slide initially but then the UI will lock up and I get the spinning beach ball. Menu doesn't respond, only thing you can do is force quit the process. Interestingly enough if you click quickly you can get it highlighted and then adjust with the keyboard arrows no problem at all, so seems to be directly related to mouse control only. Currently seeing it on 5.0 alpha but noticed the same behavior with at least the last 4 branch update or two. Anyone else seeing this issue?