BigMojo

It may be an NTP issue (12 hrs & 41 sec indicated difference)

@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.

The current distro ( v3.1.21_1 ) installs and operates properly, thanks @bpwwer

Installs and operates properly, thanks @bpwwer

@Techmanyou should be good to go with ZRTSI on Eisy with z-Matter from what I can see. It's a lateral move but it looks good.

Hi Guys! First my apologies this took so long, life got busy and I wanted to focus properly on this. ZRTSI works on the Eisy as well as it does on the Polisy. It should be noted: My application is UP/DOWN storm shutters so I couldn't test interim positioning via Motor Control Scene control doesn't currently work with the scene responders but at least it's there (not on Polisy) Scene control works with the switches BUT you will command flood. The ZRTSI likes to be spoon fed commands about every 2 seconds or more You CAN NOT query position! You eat 17 (or however many nodes you enable +1 for the controller) device addresses so there's a heavy hit to your pool versus the hoped for multichannel. The RTS radio in the ZRTSI has better range than the URTSI I'm leaving this install in place for now so if anyone would like further info, please ask. eisy zrtsi ch01-scene node object.txt eisy zrtsi ch01-scene node info.txt eisy zrtsi ch01-scene node def.txt eisy zrtsi ch01-switch node object.txt eisy zrtsi ch01-switch node info.txt eisy zrtsi ch01-switch node def.txt eisy zrtsi ch01-motor node object.txt eisy zrtsi ch01-motor node info.txt eisy zrtsi ch01-motor node def.txt eisy zrtsi controller node object.txt eisy zrtsi controller node info.txt eisy zrtsi controller node def.txt eisy zrtsi cmd flood.txt eisy zrtsi inclusion base and 16 nodes.txt

Worked like a champ, issue resolved, thank you @bpwwer !

Upgrade went fine, all seems operational but: Could some people check to see if their polyglot and pg3 log timestamps are offset by -2 hours? System time shows correctly through SSH. Let's just say that my box has some interesting challenges so YMMV but thought this was worth noting

Sadly no, I run 13 ZCombo units and they don't act as repeaters. I've kept an eye out and searched for hardwired but I haven't found any. When I first deployed zWave I had success buying some Leviton plug in switches and dimmers and that got all my smokes communicating solidly. Side Note: Our building code started out with Battery Smokes (before hardwiring was available), then to hardwired and finally back to battery units. It turned out the hardwired units would sometimes take lightning damage and brick with no indication so they reversed the requirement. Don't know about your codes but it's something to consider.

@Techman I'm running the zooz-700 on 7.17 FW IIRC. I do have a new EISY w zMatter in house that I'm about to begin bench testing my different device types on. Happy to do the ZRTSI first but I'm probably a couple days away from that if you can wait. Re: Somfy it's ironic, they were super early to the zwave party and now that demand should be on the rise.... I'll reach out to Somfy and express interest in the ZRTSI, I'd encourage any other Somfy RTS users to do the same.

I've run a ZRTSI for a couple of years on my Polisy. A few things to be aware of: It's a 300 series device, solid but slow It will include as 17 devices (1 controller and 16 nodes) I just reached out to @Michel Kohanim& @Chris Jahntwo days ago to see if I could reclaim some device pool space, it's a Somfy issue. I'll be submitting a request to them but I wouldn't hold your breath. If you've got the headroom, I would definitely recommend it vs the URTSI, no net resources to wrangle and a cleaner hardware package if it needs to be positioned in a public area to extend your RTS signal reach!