jfai

I just tried to point out that there is a way to use existing detectors and connect them to the ELK. If your house is less than about 15 years old, it already has to have interconnected smoke and CO detectors in most states to get a sign-off by the fire marshal when it was constructed. If you are building a new home or are completely replacing extant detectors with 4-wire detectors with the ELK as primary and part of the occupation sign-off, that is a different situation. I'm not advocating for or against any particular way of connecting fire/CO detectors to the ELK. Peace.

The purpose of the relay modules is to connect your existing detectors to the ELK. No need for additional 4-wire detectors. Any standard ELK input zone can be configured to function as CO or Fire alarm zone.

Thanks for working on this. I have the Tahoma Switch and 24 Somfy Zigbee motors and will give this plug-in a try once I get back from traveling.

If you already have interconnected smoke and CO detectors installed, you could use Relay Modules that tie into ELK zones. For Kidde: Kidde Smoke Relay Module SM120X Kidde CO Relay Module CO120X

If you have the eisy on battery backup (UPS) anyway, you may want to check into NUT. NUT monitors the UPS and you can get the state of the utility power and UPS battery, e.g., "UPS on battery", "UPS low battery", "Utility power restored". Then use REST to set a state variable and trigger programs. No extra device needed. Works great.

What is the reasoning to move the "Flags" node into the scene in addition to the main node? Try removing the Flags node from the scene.

These kinds of discussions pop up every now and then. The ISY programming language is not a general-purpose procedural language. Rather, the collection of ISY programs implement a finite state machine, where the IF conditions trigger state transitions and the statements in programs describe the actions when a transition is triggered.

The undefined order of execution of lines of the Then/Else clauses would cause a support nightmare. I have never noticed any ISY program behaving like this, nor did I notice any documentation stating that the execution order of lines of Then/Else is undefined.😯

A statement like "the order of execution is not defined" in the documentation of systems is common in event queue implementations (and multi-threaded processing implementations). If the programmer writes a finite state machine (IoX programs basically form a finite state machine) where the same event causes two different outcomes, that state machine is in fact a pseudo-random generator. To make the outcome deterministic, something else (another condition) needs to control the outcome. This additional condition could be specific to the system implementation (and therefore obscure) or explicitly added to the finite state machine by the programmer. Personally, I prefer to have full control over the finite state machine, so that it works independent of any particular implementation.

Dev version -> alpha release -> beta release (to select users) -> production release.

For the range tests with the Bond Pro, I used the local API with Network Resources. I would have added the Bond local API to my Node JS server and replace the Somfy MyLinks, but we sold the house before I got the chance.

No, I'm not using the node server.

I'd recommend the Bond (Pro) bridge for RTS motors - hands down. Range was enough for ~60 ft in a single-story house from one end of the house to the other. It would most likely reach further. Note: I have no first-hand experience with the Z-Wave motors.

Replace the non-GFCI breaker with a GFCI breaker. You also need to ensure that the floor covering temperature does not exceed the covering-specific maximum temperature, e.g. 82 F for anything but tiles/stone (104 F). This requires a floor sensor embedded in the heater substrate. There aren't many thermostats that have inputs for floor temperature probes.

I've been using Ring cameras to detect motion and doorbell activation long before the Ring Node server was created on Polyglot Cloud. This method still works. 1. Add the “Ring” skill to Alexa and say “Alexa, discover devices”. This will list all Ring cameras and the video doorbells as Alexa devices. 2. Using the ISY Portal, expose an ISY state variable to Alexa as a light. An Alexa light device can be set to a specific percentage value, which sets the state variable to the percentage value. 3. Use Alexa routines to set the percentage value of the light device corresponding to actions on the cameras (motion at camera X, doorbell button press, ...). 4. Write ISY programs that use the state variable as trigger.

Remove all port-forwarding rules from the router. Incoming WAN IP traffic should not reach your Polisy.

Is there any information about the recommended distance from the bridge device to a Somfy RTS motor?

It could be done using alias-to-ZID mapping. In your ISY programs, you would only use the aliases for Z-Wave devices. The ISY would use the mapping table to translate between the alias and the Z-Wave id. Then, when a device is assigned a new id, you would need to change the id in the mapping table as an additional administration step, leaving the alias the same.

I see ... you're running Polyglot version 3 (alpha). My comments apply to version 2.

Open the Dashboard from the Polisy webserver, e.g. https://192.168.0.18/dashboard. Then select System > Update Polisy. This works with all major web browsers (well, I haven't tested all of them, but I know it works with Edge and Samsung Internet. The U/I was implemented with Angular, so it should work with all major web browsers)

If your Polisy has fairly recent FreeBSD and udx versions (less than 9 months old or so), my experience is that the "Update Polisy" menu entry in the Polisy UI is working well. The update script will do a reboot as necessary, otherwise only the updated services are restarted. If you want to know what's going on during the update, you can follow the system log. SSH into Polisy, then: tail -n 50 -f /var/log/messages Note: The SSH connection will be terminated when the Polisy is rebooted.

Hopefully, a disabled program remains out of the evaluation queue. I am disabling programs because I want them ignored completely. I think what Jimbo is requesting should be done with a different program calculation mode, something meaning "evaluating but not executing". So we'd have "enabled", "disabled", "evaluating".

Great - but why are you testing 15:xx times when your ISY thinks it's after 16:00?

OK, there is something else going on. I noticed on your screen shot, that your ISY time is 16:14:08, yet you're testing with times in the 15th hour. Are your time zone settings correct, i.e., is the local time shown at the top of the Admin Console window correct?

Did you ensure that the ON time is in the future when you pressed the 'Save Changes' button? If the ON time has already passed when you save the program, nothing will happen.