JTsao

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

I did some investigation into one room where I use light switches, a remote control (via Hue Emulator nodeserver) and some commands/programs via the UD mobile app - it appears that one of 3 Insteon switches for that room does not reliably receive commands - strange, because the other 2 work fine and all 3 are in the same junction box in the room. (These are all dual band switches). I tried turning the circuit breaker on and off, pulling the air gap and doing a "restore device", "write updates to device" and increasing the # of retries to get the switch to work better, but right now the only thing that makes it more reliable is to have the ISY program turn the scene on/off 3X in a row. I am speculating that this may be a problem device and/or use of a wireless hub is less reliable than a wired one. I haven't looked into some of the other weird behaviors yet. Answers to questions - motion sensors are NOT in scenes - dual band devices were rock solid using the ISY and serial PLM

I've been running ISY-Polisy with the 2448A7 after moving from the ISY994+Serial PLM - I have noticed that frequently, motion sensors, remote controls and UD-Mobile are not consistently turning on lights (and other weird behavior) - I re-wrote a program to control the lights in 1 room using UD Mobile and added two sets of commands to set the lights up in the proper state and it works better than the version that only sends one command - this leads me to believe that commands from the 2448A7 are not making it to the devices - I have some questions about this - (1) does the Insteon protocol have an acknowledgement to verify delivery of the command? - (2) Is having the 2448A7 located right next to the Zooz USB stick a problem? - (3) The 2448A7 is within 2-3 feet of a couple of dual band light switches - shouldn't that be sufficient for the RF signal to get to the powerline? - (4) What can I do to improve this problem? (does changing the # of retries under Advanced->PLM communication help?) - (5) Does anyone else see this problem? Thanks in advance for any replies

Thanks for the replies - got it working - it's Local Port 8080 (got confused with new port #'s and conflicts with node servers)

I have the UD Mobile app working with ISY-Polisy under "Remote Connection Settings" but can't figure out the "Local Connection Settings" under Advanced - can someone tell me what to use for the "Local IP Address" and "Local Port" ? or anything else that may be missing? (When I test it says "Error: The Network Connection was lost" - I do have my WiFI SSIDs entered for Local Networks)

I have never heard of or encountered WOL authentication at work or at home and I develop networking/voice products for a living - I have used the ISY WOL feature to wake up PCs and also to turn on LG TVs - WOL should be extremely easy to fix/implement - I have written C code from scratch to generate WOL packets - it's VERY easy