Nestor

How best to do this? Some background: I have a program that sets an INT variable based on whether certain combinations of doors / gates are open. (0 = secure ; 1 = not secure. ) The monitoring program is used with a door chime so that I receive an alarm if a gate is not secure when I let my dog out into the back yard. It's a straightforward program with lots of ORs so I won't bore anyone with it unless someone feels it's relevant. Along with this program, I created a folder in UD Mobile with mapped values based on the status of said variable. Inside the folder are mapped-value icons of the various doors and gates being monitored. If the folder icon/colour indicates "not secure", I can tap on the folder to reveal which gate / door is open. Everything has been working well until one day when I just happened to open the folder (which was "secure" status) only to find one door was indicating the blue "default" icon prior to mapping. Further investigation revealed to be a dead battery, which after replacing, restored communication however this has revealed two issues: The default icon/colour of the sensor with the dead battery indicates an indeterminate third value which I haven't mapped, but I can't figure out what that value is and I don't know how the EISY got to that state. The indeterminate state described in (1.) will not cause my program to indicate "not secure." I tried simulating the node loss by removing the battery while the sensor was indicating the door was "closed" however the variable doesn't change. EISY still thinks the door is closed even after forcing a run-if. Forcing a query in either UD Mobile or the admin console while the door sensor battery is removed gives an error message, but it doesn't change the output of my program. Any ideas how I can integrate this node comm loss into my monitoring program? Thanks

Slight correction: The door sensor is an Aeotec ZW187. Apologies for any confusion this may have created. Ticket #27243 started. Will add more details to ticket as required.

(Edit: In the second screenshot in my first post, the garage door is closed. I would expect the icon to match the other two, however it reverts to the default icon values. ) You're correct that there are multiple nodes, however Access Control is the only one that appears to respond to state changes of the sensor and is useable in my programs. I created a test program and tried the different nodes in the (if) and confirmed this is the case. Access control is the only node that will change the variable when I open and close the door. New Program - [ID 0080][Parent 0001] If 'Door Sensor - Int Garage / ZY 030 Door-Window Sensor' Status is On Then $Int_Door_Var_Test = 0 Else $Int_Door_Var_Test = 1 The node in the third screenshot is similar to the others, save the "wake up" node which has status values, but not relevant for the sensor's main purpose. I have four ecolink door sensors and they all behave the same way. Hope all of this makes sense.

Thermostat is a Honeywell TH8320ZW.

As per the pics, the Aeotec ZW187 door sensor (middle icon) does not seem to want to display color and status when closed like the other two. The two gates (first and last icons) are Yo-Link sensors that seem to perform correctly. All three use the same rules for open and closed (color, icon, etc) The fourth pic shows the available values for Aeotec and FWIW, the last two pics are properties for the Yolink and Aeotec nodes. Any ideas?

Are we saying the parameter displayed in the node in the Main tab of the admin console isn’t the same parameter used in a program? In the example above, the Home thermostat parameter displays 68 deg but when I use the same parameter to set a variable, (eg. Int_Home_temperature), the variable reads 65 deg.

Yesterday I created a program that relies on my home thermostat temperature and it seemed to fail. The value provided by the thermostat is not what is being displayed in the Main devices tab of the EISY or even the physical display on the thermostat. For instance, at the time of this post, "Home Thermostat" reads 68.0 deg F and the physical display is 20 deg C (ie. 68 deg F) I put together a test program to see what value the EISY is working with by simply setting the home thermostat temp to a variable. Result: 65 deg F. As further verification, I set the variable to the heat setpoint value and got 68.0 deg F, which is correct. So it seems my thermostat is off by 3 deg, but only when being used "behind the scenes" as a value / variable in programs. Any ideas?

Thanks for your answer. All this time with ISY/EISY and I never knew this bug persisted as it did.

I have a program that I use at bedtime to switch off lights, etc, including a WAIT command to set my thermostat after several hours. I woke up this morning to find my thermostat hadn't returned to normal temperature. Another program I have keeps a rolling average of lux values from my tempest. (Thanks, @GSpitale01 ) It too has a short WAIT command and quit just before 0200. My time zone is Canada, ON, Toronto; DST checkbox is disabled. The lux program is more recent, but the bedtime program was used without issue when I had the 994i. Is this a bug in EISY or am I misunderstanding a fundamental concept about the WAIT command?

My ISP had me set up my router this way when I first signed up with them about 10 years ago. No issues.

Hi, trying to troubleshoot an Ecolink TBZ500 Zwave thermostat. I can successfully add the device but the temp setting isn't controllable from the admin console or UD Mobile. If I try. I receive a "Cannot connect" error message. Temp changes at the thermostat seem to be reflected back though. Going to the event viewer, I notice a couple of errors: ERR0 and ERR1. Couldn't find them in the wiki. Maybe I'm not looking in the right place. Any help is appreciated.

A simple test would be to switch off the keypads and see if the triggering stops.

The pop-up box to connect to wifi kept returning “unable to connect” after selecting my SSID and entering the wifi password. Neither the IP address nor ratgdov….local would work. Until they did, and I have no idea if it was due to my repeated attempts. Not sure if this is relevant, but after each reset, I’d review the boot log to look for evidence that the GDO picked up the IP address, SSID, etc of my router. Eventually they did and coincidentally, was able to access the web page via the pop-up box or directly via web browser. The boards were stable after power-down and final installation in the openers. My LAN is a recently purchased ASUS ET12 mesh.

Not sure why, but it appeared to take several reboots of the GDO and more than a dozen attempts to connect to my wifi, even though I could see the GDO's mac address in my router and the IP address I assigned it. Same thing for the second board. Also, tried a straight Discover in PG3x for the second, but ended up adding the custom config parameters as I did for the first. Nonetheless, both boards are now appearing my EISY. 🙂

Update: Noticed a new mac address in my router client list with the name "Espressif Inc". Suspecting it is the ratdgdo, I gave it a static IP address from my DHCP reservation list. After a couple of gdo resets, the wifi finally took and was able to visit the device via both IP address and local hostname. In PG3x, even though my IP address was local to the ISY, I added a custom configuration and 4 nodes finally appeared. (Yay!) Now for gdo board #2...