blueman2

Fully agree. And since I did not see a thumbs up icon in our library..... ...../ ) .....' / ---' (_____ ......... ((__) ..... _ ((___) ....... -'((__) --.___((_)

I fully support the idea of making Echo a sub-form all to itself. I think this will be one of the hottest development areas for ISY in quite some time. I think this is even more important than the ELK integration that was done several years ago. Having this buried in this forum will result in too many cross-posts in the other forums I think.

I have a program to just turn on/off the AC and Heater. It always uses the last temperature that was set for each, which is fine for us. We always keep AC at 74 and HEATat 66. Wife loves it! Have not tried the increase/decrease temp program yet. It would require being able to set a variable for currently set temp. Not sure that is doable in v4 of ISY that I am using. Maybe in v5?

I HAVE ACHIEVED WAF=9/10!! My wife has NOT been a big fan of my obsession with Insteon and the ISY. The All-On bug nearly drove her over the edge and she demanded to have every Insteon device removed. But she hung in there. Then I got the Echo. That changed everything. She now loves the insteon devices and the 'automated home'. I have the Echo controlling not just lights, but commands like 'turn on air conditioner" and "turn on door chime" (turn on ELK chime when door/window opened) and "turn on house fan" (which turns on my AirScape 3.5e whole house fan, and provides feedback when she needs to open more windows to allow for proper air flow). The Echo is working so well, she wants to add one for the bedroom to control things at night without getting out of bed. And the alarm is much easier to set with Echo than our damn alarm clock. Never thought this day would come. Now if we can add dimming and ability to pass variables (like 'turn on air conditioner to 74') then I think we might be flirting with the highly elusive 10/10 WAF.

Look for a folder called Data located where your .jar file is located. I believe that has all your discovered devices. (??)

I am in the process of moving my emulator from my Windows 7 pc over to a RPi2. Can I just copy over the data folder to the RPi to avoid reconfiguring?

Wow, Barry. This is getting pretty damn cool!

I am SO grateful for your work on this program. It really has sped up my ability to work with the Echo and ISY. Thanks for your time and energy. Great work!

Well, I reverted to version 7 of mapper, and it now works. Apparently there is some limitation to number, name, or type of programs that causes versions above 7 to crash on my system. I have LOTS of programs, perhaps too many for the mapper to handle(?)

Did you use the version 2.1 jar file from your link, or did you use the older 1.3 from this thread? In either case, I am able to navigate to the /configurator.html page which indicates my jar program is running fine. And I can talk to my isy at its IP address. But the mapper program just keeps returning the "Exception occured - send g1of4 System.Net.WebException:The remote server returned an error: (404) Not Found" error. I am stumped. Tried running mapper from several PCs with same result. I have attached the full error message. It appears it might be an issue when getting programs for the ISY?

Also, I have failed to get this to run on my Windows 7 64bit laptop. Got it to run on a pc at my brother's house, but not at my home on my PC. I run the jar program, it shows success in running, but when I try to run mapper, I always get a response "Exception occured - send g1of4 System.Net.WebException:The remote server returned an error: (404) Not Found" Any thoughts what is wrong? I confirmed the addresses of my ISY and my PC that is running the JAR.

I see directions for setting up on a Windows PC. Are there directions for setting up on a RPi? I could not find them on first read through this thread.

Neat!! And I guess I do not even need the networking module in this case, right? Thanks. And you have just made me think about about a half dozen other uses for this cool trick. Blueman2

The documentation on the networking module is rather sparse. Does anyone know if the module allows you to trigger a program based on receiving a network command from another device (in my case, an IP camera program called iSpy which can send messages via http)?

OK, I finally got it to write and it now works. The trick, as people have mentioned, is location. I had the remotelinc in the same room as the new PLM I just installed. When I moved the remotelinc across the house away from the PLM, it worked just fine. Apparently, this new PLM (2413S) has a bad radio. Same issue with other remotes that are used anywhere near this PLM. I think I may need to return it.

Exact same issue here. I had to replace my PLM and now I cannot communicate to my Remotelinc 2440. I deleted it, re-added it, and it adds along with all 6 buttons, but it continues to show the '010101' icon and gives failure message on trying to write. Exact same message as I have read in several other posts on the 2440. I have added and removed it 4 times, done factory reset 4 times. Used all different ways to add (2440, auto). Tried restore with no joy as well. Using a new 2413S V2 PLM with 9E firmeware, and 4.2.28 on my ISY and java.

Thanks, Michel. I have the highest respect for UDI and the ISY product. I also find your responsiveness and willingness to help customers to be exceptional. I will work to make the changes you recommend. I need to do some more research to make sure I really understand what I need to do/disable with my programs. That said, I am still amazed that Smarthome continues to sell a product explicitly for Garage Door Automation when there is a known bug that makes the product unsafe for that exact usage. This is not a case of the customer using a product incorrectly. I had it installed exactly as in their instruction booklet. Yes, there is a warning about CLOSING the door and making sure there are no obstructions. But there is no warning that the door can open at any time, day or night, and remain open until you manually close it. Perhaps for days or weeks if you are traveling and not home. I think Smarthome should stop all sales of the Garage Automation kit until this is resolved, and provide a recall of existing units so that customers know about this problem. We should not have to read forums on the internet to find out about such a serious security issue. Sorry if I come across as being negative towards UDI. I am not. But I am increasingly negative about Smarthome. Creating this level of risk and not warning customers about this SPECIFIC issue of a known bug is reprehensible.

Update. I now have my Garage Door being controlled by ELK (should have done that long ago!), I have removed 80% of programs that were not critical, have added 1-2 second program delays where recommended in the master thread on the ALL ON bug, and have Air Gap shut off my whole house fan until summertime. Given all these changes, I think I will be able to survive another ALL ON event should one occur. Only issue I see is WAF. If she gets woken up at 3:30am as has happened with some, or if it occurs when I am traveling, I will pretty much be forced to remove the ISY and perhaps even all the Insteon devices. Fingers crossed.

Yes, as I think you and I have laughingly traded posts on before, we all should take a page from Battlestar Galactica. Integration and automation are all well and fine until they go horribly wrong!

Thanks, Lee. This probably should be in the Bugs thread in the other forum area, but in my case there was no RF device apparently involved. I say apparently because I do have several RF devices, but they were not involved in any of the scenes that might have triggered the event based on the logs. It was either a program looping itself (I am still investigating that) or a command from an ELK motion sensor (hard wired to the ELK) that somehow triggered the event. I did recently install a DB device, but in another part of the house and apparently unrelated to this event. Only thing that has changed was a new PLM the day before (my old one had a capacitor failure so I placed with a new v2.0 PLM. Before that, I have 3 years of no issues. So I think it is fair to say that we are still not sure what is causing this. We have working theories, but no hard proof. Given that, I think prudence dictates we take a safe approach and assume this ALL ON event can happen anywhere at any time. Over time, this bug will be resolved. But until then, and until we are Five9s sure what the root cause is, we should all take the safe approach and assume it can happen.

Xathros, just read your post. You are 100% right. This is exactly what I am going to do. I am personally comfortable with any other device turning on and staying on. But my garage door and whole house fan cannot. So I have already put my door on my ELK (it was a trivial switch over since both are in the garage), and will replace my whole house fan controller with a z-wave switch and leave it air-gap off until I do. But I still think UDI/Smarthome have a responsibility to quickly and fully disclose to all consumers the safety issue involved with this bug.

Teken, your points are well taken. And anyone who is completely ignorant of safety, or who does not understand the risks we take in doing this type of 'hobby', simply should not be doing this type of 'hobby'. But what is the rationale for Smarthome to sell a Garage Door Controller? You cannot sell a device you know is inherently unsafe, and then try to protect yourself by putting a label on it saying 'unsafe'. Of course, there is not even that label. All I have seen is a vague warning not to use unless someone is near to door to watch for safety. I see nothing that says 'warning: do not use this on a garage door because it might open itself at any time'. Guys, this is a serious safety problem. It needs to be well disclosed to consumers. UDI and Smarthome have a responsibility here. This problem has apparently been around for many months. There should have been a very clear and LOUD disclosure before now about the safety issues involved with this bug.

Great input, guys. I would normally agree that taking a step by step approach to debugging is the way to go, and would normally just delete programs that I suspect cause the issue, or delete them all and add them back one by one. That is what debugging is all about. But my concerns are: 1) We apparently do not really know the full root cause of this. So any action we take is only a guess. 2) Some of us have devices controlled by Insteon that are a danger if they turn themselves on without warning and stay on Given the safety issue involved here, guessing is really not good enough. I only see 2 options 1) remove any device from Insteon control that I am not comfortable turning itself on at any time of the day and staying on indefinitely if I am traveling 2) remove my ISY Frankly, I am not sure there is enough value left to ISY if I have to go with step 1. But definitely something to consider down the road. Option #2 seems the only prudent option. Folks, we are talking SAFETY here. I don't want to have to 'debug' safety related issues. Too much risk. Either UD/ISY or Insteon (or both) needs to make a very public disclosure about this issue and fast. Also, Smarthome needs to stop selling Garage Modules immediately if their system is not safe for access control. And they need to disclose that none of their switches or devices should be installed on a device that cannot safely turn itself on at any time and remain on indefinitely if no one is home.

Due to the random ALL ON event issue, I may have to remove the ISY control box from my setup. We have a very dangerous event happen today due to this (garage door opened by itself, whole house fan turned on with windows closed), and my wife is none to happy with me. If we had not been home, it would have been bad. So I need a safe backup plan. I know I will lose all programming as well as ELK integration, but there may be no choice. So, that raises the question of how to do it? I want to keep all of the linkages and scenes if possible. Can I just power down the ISY and keep the PLM plugged in? I assume all scenes will continue to work, right? If I do need to unplug the PLM, should I just do a PLM remove in ISY before disconnecting the ISY? Otherwise, my switches will try to talk to the PLM and when they get no answer will do that funny blinking to show the comm error. I guess I will keep the ISY for modifying scenes (much easier than doing from the switches) and for if/when the ALL ON issue is resolved. Thanks, Blueman2

I have always wondered what the Hops Left and Max Hops numbers meant. Anyone know?