gviliunas

You need to create a scene and then add the button to the scene. Turn on the button by turning on the scene. It has always been that way with the KPLs. Note: Be sure to add 1-2 second delay before turning on/off the KPL button to avoid an "all ON" event. (I can't remember the exact circumstance but search for All On events and read through the long thread)

Can't Uninstall NS from NS Store list @larryllix Per your post above, I just tried to click "Uninstall" a NS from the Node Server Store list. I received a pop-up and clicked to confirm my action but the NS was never uninstalled. I tried re-starting Polyglot but still the NS remains installed and running. Polyglot v2.2.5 on Polisy, ISY v5.0.16, Tried to Uninstall ISY-Net v0.1.4

Hi Michael, Thanks for your response. No, I haven't looked for the .env file yet. In Polyglot v2.2.5, on the Settings page, there is a new parameter, "Polyglot Web Port" and it is set for 443. The page allows me to change that parameter to 3000 but it reverts to 443 upon Polyglot restart. I was assuming that this was the place to change the Polyglot web port. I'll check the .env <edit> I just checked and there currently is no "/var/polyglot/.env" file on my Polisy I can create the file but I don't know what to put in here to define the Polyglot web port = port 3000

Unable to change Polyglot web port from port 443. After following the instructions above and upgrading Polisy, I was able to connect to the web UI on port 443. Yeah!!! As a creature of habit, and after seeing, "The port is 443 but can be set in the Settings," I tried to change the port to 3000. I changed the port to 3000, clicked save, waited until the green banner disappeared and then clicked to restart Polyglot. When it restarted, Polyglot was still on port 443. There was no answer from port 3000. Note: I have not yet configured Polisy to connect with my ISY. Here are the log entries showing the port change being successfully changed, the restart, and that the HTTPS Interface Service comes back up listening on port 443: 2019-10-31 03:24:39 [polyglot] info: MQTTP: Frontend Websockets interface Connected. 2019-10-31 03:25:29 [polyglot] info: Settings Saved Successfully. 2019-10-31 03:25:29 [polyglot] error: ISY: Could not get Version. Check your settings. If this is the first time you are starting Polyglot, this is normal. 2019-10-31 03:26:12 [polyglot] info: Caught SIGTERM/SIGINT Shutting down. 2019-10-31 03:26:12 [polyglot] info: MQTT Client Services Stopping Gracefully. 2019-10-31 03:26:12 [polyglot] info: HTTP Interface Service: Stopping 2019-10-31 03:26:12 [polyglot] info: Aedes MQTT Broker Service: Stopping 2019-10-31 03:26:12 [polyglot] error: MQTT received error: Error: client disconnecting 2019-10-31 03:26:12 [polyglot] info: Polyglot shutdown complete with code: 0 2019-10-31 03:26:17 [polyglot] info: Starting Polyglot.... 2019-10-31 03:26:17 [polyglot] info: Settings: Polyglot Version 2.2.5 2019-10-31 03:26:17 [polyglot] info: Settings: Retrieved config from database 2019-10-31 03:26:17 [polyglot] info: Running in Polisy mode 2019-10-31 03:26:17 [polyglot] info: Settings: Retrieved config overrides from .env and updated database 2019-10-31 03:26:17 [polyglot] info: Aedes MQTT Broker Service: Started on port 1883 2019-10-31 03:26:18 [polyglot] info: MQTT Client Service: Started 2019-10-31 03:26:18 [polyglot] info: HTTPS Interface Service: Started - Address: 0.0.0.0 Port: 443

I checked the Polglot debug log and can confirm restarting per this repeating pattern: 2019-10-30 13:55:11 [polyglot] info: Starting Polyglot.... 2019-10-30 13:55:11 [polyglot] info: Settings: Polyglot Version 2.2.5 2019-10-30 13:55:11 [polyglot] info: Settings: Retrieved config from database 2019-10-30 13:55:11 [polyglot] info: Running in Polisy mode 2019-10-30 13:55:11 [polyglot] info: Settings: Retrieved config overrides from .env and updated database 2019-10-30 13:55:17 [polyglot] info: Starting Polyglot.... 2019-10-30 13:55:17 [polyglot] info: Settings: Polyglot Version 2.2.5 2019-10-30 13:55:17 [polyglot] info: Settings: Retrieved config from database 2019-10-30 13:55:17 [polyglot] info: Running in Polisy mode 2019-10-30 13:55:17 [polyglot] info: Settings: Retrieved config overrides from .env and updated database 2019-10-30 13:55:22 [polyglot] info: Starting Polyglot....

I initially had the Polyglot web page open. Then I did: 1. ssh to polisy2. sudo pkg update && sudo pkg upgrade3. sudo pkg install py37-netifaces4. sudo pkg install py37-cryptography5. sudo reboot Now, I can ssh into Policy and I can see the tasks running: [admin@polisy ~]$ ps -aux | grep poly polyglot 1183 1.4 6.3 833984 260524 - S 13:28 0:05.31 /usr/local/bin/polyglot-v2-freebsd-x64 -w /var/polyglot polyglot 1009 0.0 0.1 10768 2188 - Ss 13:24 0:00.05 daemon: /usr/local/bin/polyglot-v2-freebsd-x64[1183] (daemon) admin 1185 0.0 0.1 11248 2696 0 S+ 13:29 0:00.01 grep poly But, I get a connection refused if I try to access the web UI. I have tried https://polisy https://polisy:3000 https://192.168.1.77 https://192.168.1.77:3000

Thanks Benoit!! Confirmed, yes, the node-server nodes are now present in the drop-down selection and populated once again in the existing portal-exposed nodes. Thanks for your help with this! Greg

I had a few minutes so tried restoring a good backup of ISY v. 5.0.15A to rule out either ISY or Polyglot as the cause for this. Restoring the ISY backup did NOT solve the problem so I suspect that the cause for not able to expose the node-server based nodes has something to do with the Polyglot v. 2.2.3 upgrade. Upgrading Polyglot to v. 2.2.4 did not resolve the issue either.

Hi Michel, For me, the affected node servers are LiFX v2.1.16 and Harmony Hub v2.2.5 I am using Polyglot v2.2.3 and ISY v5.0.16 Any node with a nxxx_yyyyyyyy address except for the base controller nodes is now not shown in the My Device portal drop down selections. eg. I do have a "LiFX controller (n005_controller)" node in the ISY Portal "My Device" drop down selection but none of the individual LiFX light nodes appear in this drop-down. Previously, these were there and I was able to expose individual LiFX lamps as devices.

Thanks Benoit, Here is the output that you requested. I think that you are onto something. The now non-working nodes all have a type = 0.0.0.0 Thanks for your help! nodes.pdf

I recently upgraded to ISY v5.0.16 and Polyglot 2.2.3 Previously, I had exposed several of my Lifx and Harmony node server nodes via the ISY portal so that I could control these via Alexa. ( e.g. "Alexa, turn on stereo") Now, If I open the Amazon Echo device list in the portal, I can see my previously-configured nodes (See attached example of my page 11) If I click to edit one of these nodes, the My Device field is blank and can't be edited. If I try to add any Node Server-based devices, these are no longer shown in the list of available devices. Devices configured prior to the upgrade can still be controlled by Alexa but new Node Server-based sub-nodes cannot be added. I am not sure which upgrade caused the problem.

FYI: This is a copy of an issue that I posted on Amazon's support page. I am posting this here in case anyone has the same problem. In my Amazon post, I didn't mention I was using the ISY portal to provide the trigger. The device status shown in the Alexa app correctly followed the status of the portal-linked state variable so I didn't want to confuse the Amazon folks. This seems clearly to be an Amazon / Alexa app issue. ------------------------------------- -I have been using Routines for many months and have many motion-sensor triggered Routines that work properly. Today I tried to create a new simple Routine: When <my motion sensor> is active then Announce "The door is open" on all Alexa devices When I try to save this, I get a pop-up: "There was a problem creating this routine" Things that I have tried: - Create a simple routine: If I say: "Alexa, test routine" Then say "Test" - This works as expected. - Checked devices in the Alexa app and can see my motion sensor trigger and reset properly in the app. - Works as expected - Verified that some of my existing motion-sensor triggered Routines still work. - Yes, these still work. - Uninstall and re-Install the Alexa app. - No Change - Forget the motion sensor and then discover it again with a different trigger setting. - No Change - Rebooted my router and verified that both android phone and Alexa devices are on the same network. - No Change The problem seems to be with saving new Routines that involve motion-sensor-type device triggers. I noticed that my android Alexa app was updated 2 days ago. Could this have any bearing on the problem? Are there any suggestions for further troubleshooting? Are there any details as to what the error: "There was a problem creating this routine" means? -------- New information: I have an old iOS phone with no SIM but access to my WIFI network and an old version of the Alexa app. I just tried creating the Routine as described above using this iOS phone and I WAS SUCCESSFUL. It appears the the android Alexa app update that I received 2 days ago may have broken Alexa motion-sensor triggered Routines.

1. What version of ISY are you using? The "full" features of the MSII are only available with ISY 5.x 2. Most of us use the Motion Sensors to trigger lights-On but then have ISY control lights off. Please post the program(s) that you are using with your MS. 3. Please see this thread as some of the later discussions may relate to what you are seeing: https://forum.universal-devices.com/topic/25176-insteon-motion-ii-problem-on-5014-beta/ 4. Here is a link to a WIKI Article that may be helpful: https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Using_Motion_Sensors_in_Bathrooms

No, I would never try using a dimmer made for incandescent loads on a fan motor. My neighbor tried this a few years back. He called me over to help with the smoke from both the dimmer and the motor. You might be able to find a dimmer capable of handling the current but the motor will not like the voltage waveform from the incandescent dimmer.

I believe that SkyLink manufactured to first-generation of Insteon motion sensors. Within this product line, I think that there were two main versions available. I think that one version used jumpers while the other could be programmed through ISY. (Sorry - cannot remember the particulars) Beware - These motion sensors worked but are the ones that are implicated for strange behavior including ALL-ON events when the batteries get low.

I haven't tried Hue but very much like my 17 LIFx bulbs. Especially high on the WAF is LIFx in the bathrooms. My bathrooms have 4 lights on a bar above the mirror and a single 5th light in the room. All are controlled by the same switch and the wire is fed from switch to light bar to 5th light so not easy to control just 1 light. When I used regular bulbs, I had a program to modify-scene to dim them to the lowest level at night. With 5 bulbs, this was still pretty bright. Now, with 5 LIFx bulbs, I can modify the scene at night to only light the 5th bulb with a low warm glow. If needed, a double-click with bring all 5 lights to normal brightness and hue. So far, this has been 100% reliable. The only penalty is a 1-2 second delay between switch-on and light(s)-on.

LOL.....It's a "51st State" thing. Fortunately we use the same Zed-Wave radios as the "Americans"

@toddhutch I'm looking for greater range in my bluetooth, saw your post and did some searching. Didn't you mean to say that you are using Class 1 to get the extended range? According to Wikipedia (search Bluetooth): "Officially Class 3 radios have a range of up to 1 metre (3 ft), Class 2, most commonly found in mobile devices, 10 metres (33 ft), and Class 1, primarily for industrial use cases,100 metres (300 ft)." Also, there is mention of Bluetooth 5.x with a range of "40–400 m (100–1,000 ft) " but trades data rate to achieve this greater range.

Up to a few years ago, I was experiencing the dreaded "All-On" event 2-3 times per year. At that time, I had 7 of these first-generation Insteon motion sensors. I replaced all of these with ZWave Multisensor 6 and have never seen an all-On event since. I can't be 100% sure but suspect, as Techman indicated, that these sensors had a problem when the battery level was low. Sometimes just sending errant motion on signals but I also believe they were the cause for my all-On events as well.

You can use the BT in the Polisy for Presence Poly.... and can re-purpose existing rpi as additional presence poly stations to further sub-divide your castles

The weak link (pun intended) for battery-powered devices is the battery itself. My experience with the Insteon devices is that I can usually rely on the lack of heartbeat to call for a battery replacement. On the other hand and in general, I find that "tossing a coin" to be a better predictor of ZWave device battery status. When I include battery-powered ZWave devices several nodes are created in the Admin Console. One of these nodes contains a Battery Status field. After inclusion, the battery status is shown but, for most devices, is never updated again unless I do something like removing and reinstalling the device's battery. I have noticed this with the Aeotec WallMote Quads, Aeotec Door Sensor 5 and 6, and the Dome Door/Window sensors. I also receive regular communication errors from ONLY the battery status NODE of my Aeotec Door Sensor 6's. The door position reporting is 100% How can we communicate with one node of this device but be unable to communicate with another node of the same device??? My dome window sensors work 100% for window status reporting but never for battery status. I have over 35 wired and wireless ZWave devices in 1000 sq ft so think my network is good. On the other hand, the battery status reporting for the Aeotec Multisensor 6, seems to work most of the time. Why does this type of device usually (but not always) correctly supply battery status? It seems that either something is missing in the way ISY handles battery status communication or problems with ZWave battery status reporting in general. If the ZWave devices / ISY cannot be made to speak properly, it would be nice to be able to turn off those annoying "Can't communicate with battery status node of xyzzy sensor" pop-up messages. Has anyone experienced this? How do you deal with battery-powered devices? Do you replace the battery on a schedule or just wait until something stops working?

I would upgrade to 5.0.15A Beyond that, all battery-powered devices need to be awake in order to display or set any parameters. How to do this is also determined by the OEM. Sometimes it can be as easy as leaving the top cover off, sometimes you can press a button, sometimes, you can power the device via USB (Aeotech products). It depends on the device. Unfortunately, there are also devices that you need to have good timing and activate the device (open or close the door) and immediately click to perform the parameter set / query - These can be a challenging hit/miss affair... Welcome to the Wild West of Z-Wave. From the Fibaro manual for the door / window sensor: "Waking up the Door/Window Sensor: The Door/Window Sensor needs to be woken up to receive information about the new configuration from the controller, like parameters and associations. To wake up the sensor manually, click one of the TMP buttons (while the other button is pressed)."

I tried it but could never get it to work. Returned to Amazon.

If you need line-level heat-only (No fan control) thermostat to control 110-220 baseboard heaters, I've been using five Stelpro STZW402+ thermostats that seem to work well with ISY's Z-Wave. These thermostats have no local schedules so this must be done through ISY. There are two modes of operation, Comfort and Eco (Setback). You can switch between modes and change the Comfort set-point from ISY but you can only set the Eco set-point locally at the thermostat.

Recommendations for the Wakeup field on a Z-Wave node. I Noticed that for every Z-Wave device, there is a node with a wakeup button in the middle of the page and a field to enter a time value. - What does this do? - Are there recommendations for setting this? - How does the "wakeup" button relate to the "Write Changes" button at the bottom of the page? I was watching the Admin Console and the event viewer while investigating the z-wave backup issue and noticed that my EcoLink Z-Wave front door sensor was, once again showing "!" cannot communicate status. (Grrrr there is a AEON doorbell within 7 feet) On a lark, I pressed the wakeup button and saw, in the log that this had sent a wakeup interval of 0 seconds to the EcoLink. The device awoke and is now back in my Admin Console tree. I tried other values for the wakeup time interval (300 seconds, 5 minutes, 10 minutes) . Every value I tried, except 0 seconds resulted in the device status reverting to "!" Is this expected behavior? Should the wakeup interval be "0 seconds" for this device?