GHenry

Best advice is to forget about it. It's pointless to keep asking and asking. It'll be ready when it's ready, and not before. No one can foresee when the obstacles will be overcome; that's an unknowable unknown.

Wow, thank you both! Sometimes the obvious solution isn't quite the best solution.

Eisy v5.8.0 I have a logic problem! A program sets a state variable to 0 or 1 depending on sunset and luminance. A second program turns lights on or off, depending on the value of that variable. It works very well on gloomy days…until 32 minutes before sunset, which was at 5:27 p.m. At 4:44 p.m. it correctly emailed me that “lux level dropped to 13 lux. Eisy turned on selected lights.” And then at 4:55 p.m. (35-3=32 minutes before sunset) it illogically emailed me that “lux level increased to 13 lux. Eisy turned off selected lights.” Lux level did not increase, and at 13 lux, Eisy should have turned lights on, not off. This happens frequently on gloomy (but not on bright) days. Obviously, I’m missing something here. Can someone please correct my logic? Den Low Lux 15 Variable - [ID 000A][Parent 001D] If From 8:05:00AM To Sunset - 35 minutes (same day) And 'Den Temp and Lux' Luminance <= 15 lux Then // Wait for both conditions to test Wait 3 minutes $Den_Low_Lux = 1 Else // Wait for both conditions to test Wait 3 minutes $Den_Low_Lux = 0 Den Low Lux 15 Send - [ID 0019][Parent 001D] If $Den_Low_Lux is 1 Then Set 'LR1' On Set 'LR2' On Set 'BR' On Set 'Bar' On Send Notification to 'Notification List' content 'Den Low Lux Email' Resource 'Den Low Lux Message' Wait 15 minutes // …to prevent rapid switching Else Set 'LR1' Off Set 'LR2' Off Set 'BR' Off Set 'Bar' Off Send Notification to 'Notification List' content 'Den Low Lux Ended Email' Resource 'Den Low Lux Ended Message' Wait 15 minutes // …to prevent rapid switching

Thanks, I guess I'll try yet again, though it's working okay. The device was always within 3-4 feet of the Eisy, but I didn't factory-reset it. Twice the updates hung, and after 45 minutes I aborted the updates (despite dire warnings). It drives me nuts when I follow the same procedure but get different results. The thought that "if it ain't broke, don't fix it" comes to mind…the update isn't all that compelling.

TriSensor ZWA005-A V2.17, Eisy 5.8.0 I have successfully updated one TriSensor to v2.21. Following the same procedure, when I attempted to update the second one from v2.16 to v2.21, the update appeared to have completed fully and correctly (Eisy said so, and it took 20 minutes!). After repowering the TriSensor and rebooting the Eisy, checking command class 134 says that I’m still on v2.16: Integer DATA devices.15.instances.0.commandClasses.134.data.applicationMajor = 2 (0x00000002) Integer DATA devices.15.instances.0.commandClasses.134.data.applicationMinor = 16 (0x00000010) What am I missing?

Now, that's elegant. Thank you!

Your more thorough insight demonstrates that I'm not an elegant programmer. The node usually updates only every 6 hours, but special weather situations might cause it more often. And "Thinking about the two programs some more" is what I failed to do! Thanks for following through.

That's a good suggestion, thanks!

Interesting, thank you! Both emails are sent at the same time, down to the second, so I wouldn't have thought of that. But since I operate my own mail server, I can see in the logs that in fact the two emails are sent exactly 0.3 seconds apart: 05:56:18.268 2 SMTPI-001601([192.168.1.1]) [8211038] received encrypted, 849 bytes 05:56:18.568 2 SMTPI-001602([192.168.1.1]) [8211033] received encrypted, 849 bytes I guess waiting one second would do it. Thanks again!

eisy, IoX firmware & UI v5.8.0, Java 8 update 401 (today), MacOS 14.2.1 Regarding the attached program snippet, from a pure logic point of view, I’m thinking that if either one of the two “If” conditions is false, then the whole “If” condition is false, and therefore the “Then” step should NOT execute; if either one of the two “If” conditions is true, then the whole “If” condition is true (either/or), and therefore the “Then” step should execute. Once. NOT twice. Either the “If” condition is true, or else it’s not true; it’s binary, there’s no in-between! If either condition is true, then the condition itself is true…but only once; if neither condition is true, then the condition is false (once). Curiously, if I right-click on the program and choose “Run (If),” then I only get one notification, as expected. Am I missing something here? Why does the “Then” condition trigger twice, but only when auto-executed?

Under Tools/Trend (Chart), there are various items to chart. I’d like to request two updates: first, please add the ability to chart Lux Level; and second, please alphabetize the list (on the basis that any order is better than no/random order). And thank you! Cool Setpoint Current Current Current Power Used Current Temperature Current Voltage Energy Mode Heat Setpoint Humidity Lux Level On Level Polarized Power Used Power Factor Ramp Rate Status Total Energy Used

Yes!! I have the -A version of that sensor, and it works great with eisy and the UD Z-Matter USB dongle. I use it outside of normal programming times to turn on the lights when it's a particularly dark and dreary day (15 lux). Like you, I had never tried Z-Wave before, but installation is pretty much automated (though it took me a few tries to get all the details right).

Yes, I did. Inconclusive. Since the admin console seems to work fine notwithstanding the error dialogs, and apparently no one else is complaining about the problem, it doesn't seem worth the effort to try to track down the source.

Many thanks for both the specific answer, and the link, which is really useful for the future!

After a several deletions of Java cached applications and applets plus installation of IoX 5.8.0, I’ve resolved everything but the first item above, the “AutoUpdate Status/Authorization Failed!” dialog. Given the UD logo, I’m guessing it’s not necessarily a Java problem. Where does that dialog come from, what does it mean, and what can I do to resolve it?