BigMojo

@vbPhil SSH sudo pkg info isy will give you the full version (et.al.) info

Installed smoothly, seems to have fixed up my 5.6.3 zWave glitch. I did go through and re-interview all my ZYs, a handful of devices want re-inclusion but everything else is running MUCH better! Thanks to the entire UDI team for all your efforts !!!

You might look for a local provider to perform a Blower Door Test. There's two basic flavors, Whole House and Differential. The basic concept is: Seal off the HVAC ducts (notoriously leaky as mentioned above) An airtight fabric "door" with a big fan is hung in a doorway, window or whatever penetration you can use Using a manometer (measures differential pressure between two points) tune the fan speed to de/pressurize the space to 50 pascals. This will give you the ability to calculate the industry standardized ACH (air changes per hour) value which is the definition of how "leaky" a space is. This test is actually mandated on new home construction in many jurisdictions so it's likely you have vendors nearby. All credit on this to Matt Risinger of the Build Channel (highly recommend) Build Channel - Blower Door Intro

Hey @Goose66, Big fan of your work and honestly I'm hesitant to even offer... Especially when I forgot what forum I was in....

I'm sure this is already in the works but thought I'd throw it on the pile 😁 Query All is currently sequentially processed. In my case: Insteon devices are queried (~150 devices = 1 min) zWaves next (~150 root_device_1s = a few minutes) Concurrent processing would Let each protocol operate independent of others Isolate communication delays, hangs and/or resets to that stack Provides the foundation for future protocol implementation(s) Further leverage the eISY hardware .... you guys get it (and know what a major effort this would be) ....

Have the work queue query the parameter, capture the byte size and append that dynamically to the write parameter command issued. Pro: no mismatched sizes in programs, potentially negate any device level errors due to bad incoming data. Of course the device firmware SHOULD be handling this but driving one's own ship is usually safest. Con: More zWave traffic and delayed code execution vs. "hard" writes. It's a parameter update, is code speed really a consideration? Optional: I.e. if the program contains the size, process the command unmolested, otherwise retrieve and append the size? This could be a nice differentiation for maintenance (slow) vs. production programs.

Being able to perform operations on a folder's children could reduce stored code size and maintenance greatly. Basically, treat a folder like a scene but without real links. I.e. enumerate the members at code execution and perform the same action on each of them individually. A Virtual Folder might be cool where the same device could be a member of multiple Virtual Folders, such as FLOOR/, ROOM/, INDOOR FANS/, etc... Query SHUTTERS/ vs. Query SHUTTERS/Shutter-1 Query SHUTTERS/Shutter-2....

So much data available, a bulk reporting mechanism like the Topology feature would be wonderful. My current use case would be to dump the application.major & .minor values to audit my device's installed firmware. Eventually, filtering would be nice but I'd rather wrangle the bulk data than copy/paste by individual device.

@vbPhil you might find this helpful: https://products.z-wavealliance.org/regions/2/categories/10/products I would caution that whichever direction you go, you should verify that the thermostat will indeed meet your use case needs. I fell into the Trane/American Standard zWave tstat trap myself with the XL1050 stat. Sure it’s zwave certified, has what appears to be the correct command classes but… Other than static controller functions, none of the system controls or parameters are exposed via zWave rendering automation impossible without an Asairhome/Nexia cloud subscription. It is zWave but crippled to drive revenue to their cloud service. I’m running 12 tons on 3 systems (2 fully variable, 1 std), great equipment, huge run cost savings but a giant disappointment as far as automation capabilities with or without their cloud service.

@landolfi, I can't speak to the root cause, that's best left to the team. I can say that my issue was communications related evident in a corruption of my zWave device definition file(s). Without putting a timeline on when the new package will be released, I can tell you I'm fully backed up (2x) and ready to go on the upgrade. Read into that what you will 😉

@TexMike, I have the same issue and @Michel Kohanim, @Chris Jahn & the team have been busting butt on this issue. It's my understanding that the fix is in final testing and the solution should be here very soon.

@TheA2Z ^^ Excellent ! I just did over 100 Zooz FW updates (no bricks) and would also suggest: Disable what you can on IoX to reduce network and log traffic (programs, node servers, etc). Make sure the battery > 80% before inclusion 1' - 10' unobstructed view of zWave antenna. This speeds things along greatly during interview If you have SSH access: sudo tail -f -n 500 /var/isy/FILES/LOG/ZWAY.LOG I found this helpful because: It's a lot easier to observe what's actually happening on the zWave network The device can still be actively communicating with IoX but the blue indicator may not always be flashing. Once the zWave interview timeout reaches ~200-150, triple click the sensor to reawaken it. This gives the unit more time to interview without getting (too) bogged down by spamming wakeups. Repeat until the interview completes or the unit stops actively sending info other than wakeups. You will quickly recognize what a good vs. bad inclusion looks like in the ZWay log and can respond appropriately. Hope this helps

GLASSY Smooth Update ! Well done and thanks to @Michel Kohanim @bmercier & @bpwwer for all your efforts!

@dbwarner5, I can tell you I’ll be looking at my router’s logs (Syslog’d to NAS) to see if/when anything is getting recorded for the IOX’s MAC/IP. A quickie test would be to modify your router DHCP lease time to as low a value as you can and see if that changes your failure frequency. If so, raise the lease time to a large value to correlate a greatly reduced fail frequency. I’m tied up with the holiday weekend but I’ll take a deeper look in the next few days to see if I can replicate your condition. Happy Memorial Day everyone!

I’ve been seeing the same behavior also. Would it be possible to insert a connection drop timer variable before the notification triggers? This may also be a DHCP renewal but I haven’t had a chance to look at that yet.