JTsao

Wow I just learned about the Bond Bridge - the thing I like about it is that it allows to use the native RF controllers that came with my ceiling fans (Casablanca and Minka Aire models) - that would allow for accurate control of 3 speeds. I was running Fanlincs and the speeds were always off. Over the years, the Fanlincs failed (5 of 6) and I ended up replacing them with an Insteon On/Off switch paired with a capacitor which left me with a single speed fan. (I have two switches wired in each room per fan, one for the light, one for the fan). I just installed an Enbrighten Z-Wave Fan Control in 1 location for $40 - but I could have purchased the Bond Bridge instead for $100 for 6 fans and started using all of the RF controls that I already have sitting in a box. Darn it. is it necessary to buy the Bond Bridge Pro? Or does the regular Bond Bridge suffice to control multiple RF ceiling fans?

I agree about preferring a hard button remote vs. the iPhone and would love to have a replacement for the ISY994 IR input. What happens when a USB keyboard is plugged into the Polisy? There is a USB device known as a Flirc, that converts learned IR commands into keystrokes. It has low cost and I can't imagine it being a stretch to get a Linux based microcomputer (the Polisy) to process keyboard entered commands. Any thoughts?

There is no IR on the ISY-Polisy (IoP). I was using IR on the ISY994 but now on IoP I am using only the dedicated home control buttons on Logitech Harmony companion remotes to control lighting and fans via the Hue Emulator Node server and the Virtual Node server. In my case, pressing a home control button turns on a virtual switch, which can cause a program to run. The switch has to be in a scene that is associated with the Hue Emulator (Notes->Spoken="1"). I am also using the UD Mobile app more in my house for controlling things.

I would agree that the USB stick is not as good as a PLM, but I have been staying with it since my switch to IoP and overall it seems OK - one thing that happened to me, that may or may not apply to others switching to IoP and trying the stick is that it seemed like the device links were not all what they should have been for a lot of Insteon devices after the IoP change and the restore PLM operation - After checking a lot of device links vs the ISY links and doing a lot of "restore device" operations, things improved (a time consuming task)

Updated and everything seems OK. Question - how do we know if the Polisy requires a re-boot after updating? I have been rebooting after updating in the past, but now with IoP running, I don't really want to reboot unless it is needed. Is it better to update via SSH + "sudo pkg update sudo pkg upgrade" vs. the web page? (because there is more feedback via the SSH terminal about the update vs. just a couple of beeps). If you type "pkg info | grep -i ISY" before and after the update and see that the ISY, PG3, Polyglot2 and udx versions have not changed, does that imply that each of those things does not have to be restarted?

I have been checking almost daily for Polisy updates via the System->Check for Polisy Updates menu and have been appyling the updates as they come out. There's been a lot of updates recently, but I don't think any of them have caused any problems for me yet. I just checked and now it says 100 packages available for update. Is anyone else seeing this many? I have never seen anything close to that amount and am concerned that something might break. Has anyone actually applied these updates?

In my opinion, Insteon is still the best option for in wall switches - I plan to continue using mine for a long time. Also, with ISY on Polisy, you can upgrade to a much better Z-wave controller (Zooz USB stick) - with this controller Z-wave works much better - I am in the process of adding some additional Z-wave equipment including a motion sensor, in-wall outlet and plug in smart outlet - some of this type of Z-wave equipment may be a better option going forward than the Insteon counterparts - for example the Insteon on-off module plastic always breaks and I think the battery life on a 700 series Z-wave motion detector will be longer than the old Insteon MDs - not to mention, supply chain problems preventing the ability to buy the Insteon parts - so far all of my old Z-wave locks (300 series) and other Z-wave plus equipment has been working WAY better than with the ISY z-wave module

That's good news - I ordered one - looking for a low cost alternative to the Insteon On/Off module - the plastic on those things is really flimsy and several have broken - with IoP+Zooz stick, Zwave is now a viable option

On Amazon, the referenced plug is about $27 - much cheaper than the Aeotec smartswitch 7, but I am not 100% sure if all z-wave devices will work with the Zooz stick and IoP

In my experience, both of the ISY z-wave modules (300 and 500 series) had poor range and performance compared to the Zooz USB stick that I am now using in the ISY on Polisy - some communications issues with older Schlage Locks and other devices never were completely resolved by using Aeon repeaters with much shorter distances than 50 ft - but now I have much better range and communication

FYI you can also type "sudo cat /var/udx/logs/log | grep bios" to filter the logfile for the section of interest

Is there an updated admin console available for 5.4.1? After this update, I cannot get into the admin console - it says I need an updated version (my admin console is apparently 5.4.0) UPDATE: nevermind - I cleared the java cache and re-clicked the admin console link on the Wiki and now I can get in - sorry for the false alarm

If I right click and do set configuration parameter like you are suggesting above, then it appears that I can set the parameter to values > 127, however, I set it from the main screen which looks like the attached image below, parameter number=5, parameter value=X, then X is limited to 127 on this screen After switching to ISY-Polisy and switching from the serial PLM to the 2448A7, I have noticed that sometimes Insteon messages are being missed, therefore, I changed my programs for motion sensors to use a state variable, so I can track if the lighting in the room matches the state value.

Due to the complex nature of jointly controlling lighting in rooms with both a motion detector and a manual (Insteon) switch, I never put the motion sensors into a scene - I use a state variable based state machine to coordinate turning on and off via MD or manually - I also have been using a GE Enbrighten z-wave plus in-wall motion sensor in my kitchen for a couple of years now it works great - one thing - I found a problem in the ISY-Polisy that you cannot set the timeout duration to greater than 127 seconds in the ZSE40 (parameter 5) - it should accept a full 8 bit value, but for some reason, the menu does not allow that, so the timeout can only be max. 127 seconds

I bought a Zooz ZSE40 700 series this week $36.95 - it is working well so far (for about 2 days) - what remains to be seen is battery life...

I did the 6 button procedure and the UDX update and I see a button on the Configuration/System tab that says "Enable TPM" that is not greyed out but needs to be pressed - so at this point does that mean I have successfully done the BIOS update? It appears that TPM is not yet enabled on my IoP at this point - should I push this button? Has anyone done this?

After reading the above post, I also re-tried pushing the button 6X, waiting 1/2 hour and then pressing the button 2X and now the left LED is solid and everything appears OK so far...

Thanks - I had actually pushed the button 6X after my posting - after pushing the button 6X, all 3 LEDs were blinking - I waited about 25 minutes and the LEDs didn't change so I did a "sudo shutdown -r now" and after the Polisy rebooted all of the Insteon devices appear to be back - now only the left Polisy LED is blinking, but on the Wiki page it says that the 2nd or 3rd LED indicates and old BIOS, so I am not sure what that left LED blinking means and not sure if the UEFI BIOS update was successful - will test ISY functionality over the next couple of days

I updated and when I start the ISY admin console it says "Failed to communicate with..." every Insteon device in my system. There is a red exclamation next to every device. Also, I tried to reboot the Polisy via the web interface and did not hear any beeps. The leftmost LED was blinking before I tried to reboot and now the middle LED is blinking while the left LED is ON steady. Any suggestions here?

I haven't updated yet but don't you have to do "sudo service isy restart "?

With the 2448A7, I observed two obvious cases of communications problems: (1) room lights activated by motion sensors (which are not directly linked to scenes/devices) and (2) room lights controlled by a remote control (Harmony Hub -> Hue emulator). In case (1), walking into the room would sometimes NOT turn on the lights and in case (2), pressing the remote control button would sometimes result in lights not going to the proper state. Both cases seem to have improved by either (A) sending the scene command 2X in the ISY program or (B) sending the scene command to turn on, then sending devices commands to turn them on/off per the scene in the program. (BTW - there are reasons why I don't have the motion sensors linked directly to the scene devices.) I realize that it is not ideal to have to send commands 2X, but it seems to make things work better. So I have a related question regarding the "link type" scene options = Insteon, Command, Default and Ignore. Currently, all of my scenes have devices set to "Insteon". Will changing the link type for a device in a scene from "Insteon" to "Command" make commands to turn on Scenes more reliable in this environment where sometimes messages get missed? Does it result in device commands being sent rather than scene commands? I read that devices commands get an acknowledgement, but scene commands do not - is this right?

So you're saying that in PG3, pushing the button on the Harmony remote sets the associated scene with the light set to off, and you have a program that runs like the following: if 'Lt Switch' is switched off then (action here - ignore motion sensor, or whatever) and it doesn't work with the PG3 Hue Emulator? In my program - I use the status of one of the lights I intend to control which signals a program to run if 'Lt Switch' status is 10% then (action here - e.g. increment state variable) - In my case, using PG2 this runs right away when I push the button, activating the scene where the light is set to 10% If the ability to trigger a program is broken in the PG3 version, then that is indeed a big problem

Just read this and want to see if it applies to my use case as I just installed Polyglot 3 (haven't used it yet) The only way that I have figured out to get the Hue Emulator V2 to run a program on the ISY is to create a scene (with Notes:spoken=1) which (for example) sets a light to 10% dim - then I have a program that runs using: if '... Lt Switch' Status is 10% then (take action) Is this the kind of situation that you are talking about? Or Is there another way of getting a program to run from the Hue Emulator? Someone once mentioned "fake scenes" but I don't know what that means or how to do that. For me, this capability is critical as I really want to be able to run programs using the Harmony Companion Home Control buttons, not just turn scenes on and off

After some experimentation and after combing through the forums, I think I have learned some things about Insteon: 1 - If an ISY program sends a command to turn on a scene, there is no verification, checking or retries to make sure all devices are actually on (although it appears the Insteon protocol may support this) 2 - if an ISY program sends a command to turn on a device, the ISY performs a check to make sure it is on Can anyone confirm that the above is true? My conclusion is that if I see instances where a scene command doesn't consistently work in a program, I should try re-writing and issue individual device commands to the devices in the scene instead. This appears to be the case, but I probably need to test further. Obviously, this is more practical when dealing with a small # of devices in a scene. I have also seen that sending the scene command more than once also increases reliability. For some reason, I have also observed that, in my case, an ISY program sending two consecutive scene commands to turn on/off two devices right next to each other (one in each scene) is less reliable than sending a single scene command to set those same two devices to the desired states (if they are both in the same scene). I am not sure of a good reason why this is happening, but this is how the program was operating when I first noticed issues. Overall, since I have been performing some program cleanup and reorganization with scenes, state machines, etc., I am unsure if introducing the 2448A7 is directly related to some problems that I have observed or not. Modifying the programs per above seems to have increased reliability, but I am not sure if it is at 100% (need more testing). Can anyone comment on whether or not a wired PLM communicates better than the 2448A7?

I re-coded all of my motion detector rooms to use a state machine with state variables - I can see that the lighting sometimes does not match the state - this indicates that the command to turn lights on or off is not being received for some reason - I have a LOT of Insteon dual band switches in my house - not sure why the commands sent from the 2448A7 are not being received