GHenry

v5.8.4. I repowered the eisy, but still got the same odd sequence…the first query gives the "mail server failure" dialog; the second and subsequent queries get only the expected "request failed" dialog. But now it isn't consistent; after quitting and relaunching the client, sometimes, but not always, do I get the "mail server failure" dialog. It's like that other "authorization failed" dialog I get after every login, although everything seems to work just fine: it's really not worth the effort to track it down. Thanks for your offer to help, but let's table it for now, with the new non-Java interface forthcoming…

eisy v5.8.4 Okay, I’m puzzled: the first time I query a device (which happens to be offline), I get a dialog about mail server failures; that’s not expected. But when I do another query, I get the (expected) “request failed.” The event viewer is not elucidating. I don't know of any connection between the queried device and any email notification (I do have notifications, but not for that device), so what's going on?

What video surveillance cameras do you suggest for use with eisy/HomeKit (planning ahead…)? I believe one requirement is RTSP support, right? I asked my AI for a list of video surveillance cameras that support RTSP. Trusting AI (not!), I’m asking the forum for suggestions. AI gave me the following list; is it on-point, or off the mark? Reolink RLC-810A Reolink RLC-811WA Topodome RTSP WiFi Bullet Camera Topodome 940nm RTSP PTZ Camera Alptop 8MP 4K PTZ IP PoE Dome Camera SV3C PTZ Outdoor WiFi Camera ZOSI 4K PoE Security IP Camera Amcrest cameras UniFi cameras Any suggestions welcome; thanks in advance!

You again! Thanks again for the quick response! When I got the blue flash and clicked query several times on the 8s (close to the eisy), I always got the attached dialog from the eisy; meanwhile, the Event Viewer always shows [ZWAVE-TEST-AWAKE 17] Device 17 is not awake So, following your lead, I did the ultimate wake-up: I removed the battery for 10s, replaced it, and clicked Query, and both devices now report battery (one was 95%, so it failed to report on change). Thank you again for your help.

eisy v5.8.4, Z-Wave, Aeotec TriSensor 8 Battery Level does not appear/report for my TriSensor 8s, but it does for my TriSensor 5s. Node info for my two TriSensor 5s say: <property name="" uom="51" formatted="77%" value="77" id="BATLVL"/> <property name="" uom="51" formatted="100%" value="100" id="BATLVL"/> However, the TriSensor 8s both say <property uom="0" formatted=" " value="" id="BATLVL"/> The 8s both do report temperature and luminance, but Event Viewer shows entries like this for the 8s (never for the 5s): [ZWAVE-CTL-EVENT ] Basic Set from 18.0 unmapped (ignored) How can I get the TriSensor 8s to report their battery level?

Yeah, that did it, thanks again, Techman! I didn't even need the power-off. Curiously, there were four small files of about 50k from each failed attempt at backups. Like everyone else's experience, it was so fast that I had to check to see whether it actually saved this time (it did!).

Eisy 5.8.4, iMac, MacOS Sonoma 14.5 I did some updates, and when I tried to back up my eisy, I got two dialogs in rapid succession: Could Not Parse the Configuration File Could Not Create the Zip File I tried several locations; it's not a permission error. I quit and re-launched IoX Finder, no joy. What does this indicate? How can I back up my eisy?!

Yeah, that did it (eventually!), thank you, Techman! On the first one, it took 5 tries (timing is everything!).

eisy v5.8.3, Z-Matter USB I have 2 Z-Wave devices (Aeotec TriSensor v5 and v8) which report correctly, but have green binary arrows pointing to them in eisy’s main view. I have tried to wake up the devices and write, but the writes fail (device not awake) and the arrows persist for days—even after an update to IoX v5.8.4 and a reboot. What am I missing?

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?

Wow, that was easy, thank you! But how can I access the numeric percentage reading itself? I'd like to report via Notifications and email the actual battery percentage number.