I’m not sure what “software update via smartthings” could mean other than a firmware update, but especially with that build date, it doesn’t look like this is a new firmware image.
When I saw the prompt/alert in SmartThings for a “Software Update” every time I added a new Juno bulb (e.g. not to update the mobile app itself) - I got excited, thinking there was a firmware update. Guess not.
Exactly. Not all that long ago ST said there were no plans to implement OTA for attached Zigbee devices. Interesting that Acuity suggesting pairing w/ST. “Software” sort of suggests firmware, particularly since you are going to remove the device and add it to another hub after the “update”.
Just curious if anyone is having any level of success with Juno Connect. I’m in the process of building and have about 60 of these I’m hoping to install. Has anyone tried a zigbee network with just a hub and Juno Connect devices that are always powered? I’ve purchased the Inovelli Blue switches to keep the wafers powered in hopes of avoiding zigbee routing issues. I’m also debating using high density zigbee repeaters such as the SonOff repeater and am wondering if anyone has found improved performance with repeaters. Any feedback is greatly appreciated.
Nah, still almost unusable here. I’ve given up using them and started working on other projects. If I don’t see a firmware update by the time I circle back to this project, I’m trashing them.
Usable as in they work fine to turn on and off by applying and cutting power, but as for staying connected on a Zigbee mesh and dimming them and changing CCT. Let’s put it this way, if I had hair I’d have pulled it out by now.
Still waiting on a promised firmware update that was having the finishing touches put on it in February.
If there was a good Zigbee bindable 4" wafer that had gimbal version and regressed (baffled) versions I would have yanked and swapped these by now.
Seriously frustrated at this end. Biggest blunder/mistake in our renovation.
If anybody knows of 4" alternatives, I’m all ears.
I reached out to Juno tech support to see if there was any update on the firmware update to fix the Juno Connect lights. The technician that I talked to, Darnell, was aware of the issues and reached out to what I understood to be the lead engineer for the project. Darnell got back to me and said that breaking up larger systems into smaller networks (approximately less than 30 devices) would help but that the issue of devices locking up and needing a complete reset would continue. According to the engineer, they believe the issues are due to using Samsung chips and they now to release a new version using different chips in approximately 6 to 7 months (end of 2024). Darnell sent me a follow-up email stating that Juno would replace any defective devices with the new units once they are released. Obviously waiting 6+ months for a resolution that may (or may not) fix the issue isn’t ideal. Thankfully they are being transparent and offering a resolution even if it is delayed. I plan to install a much smaller network of Juno Connect lights using Blue series switches and use “dumb” lights with Blue series switches for the remainder.
Longer version: I’m using Zigbee2MQTT and Home Assistant. I have about 30 of these because there’s no other option for 4" recessed can lights. They kinda work okay?
The main issue I have is that the coordinator will hiccup (or maybe that’s not even what causes it!) and the Inovelli blue switches will do some sort of reset dance which results in all the lights turning on then off, then on again. It doesn’t send the lights into pairing mode, but sometimes this also means some of the lights just don’t seem to be part of the zigbee network anymore. I can’t tell if this is an issue with the Inovelli switches or the lights. I’m betting it’s the lights, but I also wonder if there’s some known case where the blue switches will do this type of power cycle?
I have all my lights bound to blue switches, and that works pretty okay for a while. At least until the reset dance.
I can also confirm that the issue happens on HA ZHA, Habitat C7, and Aeotec SmartThings hub (latest gen.).
If I don’t include any of the wafers, 54 blue switches work 100% right.
If I put wafers and blues on the same mesh, I will occasionally get switch reboots with Ukrainian flag color sequences, but this only happens on the SmartThings mesh.
I have not had any reboot issues on HA ZHA meshes with wafers and switches together.
Wafers are my root cause of issues/hangs, and disassociated lights. That happens on ZHA and SmartThings (and habitat).
Okay, so while we know the wafers are garbage, maybe there’s some value in pinging the Inovelli folks to determine why their switches go into flag mode and do that reset dance? ASSUMING the thing the switch does is the cause of the disassociation?
@Eric_Inovelli, you used these wafers during the initial days of this thread. Any thoughts?
Sorry if some of this is in the manual somewhere and I missed it.
I haven’t tested these for a while, but that seems really strange to me. I only have 4 Junos connected anymore and I only use them as on/off in full-sine mode. Haven’t noticed anything strange like that. I’ll ask the engineer if he has any ideas.
I at one point added a bunch of these to a network and they had a lot of problems. The lights would just stop communicating and I ended up giving up on them. Is it only since firmware 2.18 that this happens?
I have little more information: I have 10 blue switches all on the same zigbee (z2m) network running the UZG-01 coordinator (zigbee stack 20240316, firmware 20240612). 8 of the blue switches are bound to groups of Juno can lights. 1 of the blue switches power WiZ bulbs. I had a few sets of switches bound to the can lights reset at the same time the ones that power the WiZ bulbs reset. I think this rules out an issue with the electrical load?
@lavid,
What hub do you use? I’ve only seen my Innoveli Blue switches reset on my Aeotec Smartthings hub, and it’s happened far less in the past months since Samsung/Smartthings has updated the firmware on the hubs.
Separately, I’m still in contact with Juno/Acuity. The firmware update they were working on “putting the finishing touches on” (their words) in February is still delayed. I guess they found another issue last week so the latest communication is they’re targeting a late July release. This firmware update from Juno/Acuity is supposed to fix the connectivity drops/hangs/autonomous factory resets.
Wait, Juno is working on a firmware update to help with all the strange network issues that they experience? That is actually pretty great if true.
I’ve relayed the “neutral” info to the engineer and will let you know what he thinks. If there is anything else that is unique about the install that you think of let me know and I will pass it on.
@EricM_Inovelli,
Juno is working on a firmware update. I’ve been keeping in contact with a director there on about a monthly basis. They say they’ve been able to replicate the issues, and it was tied to timing sequence. On/Off commands where the fixture tries to generate a confirmation message, and the wafers generate an offline or not responding error message which then makes the wafers hang, requiring a power cycle sometimes, or a factory reset to regain connectivity.
-Feb 7. 2024: Putting the finishing touches on a firmware update to fix the “dropout issue”
-Monthly touch bases: Still in progress
-June 10, 2024: “Confirmation this morning that the new firmware for our Smart Wafers and RetroBasics will be released next week”
-June 20, 2024: " the firmware team identified another issue they believe is contribution to the connectivity issue. They believe the firmware update should be delayed to include corrections for the new issue. Of course, this will require additional testing. The new scheduled release is for the end of July."
My hope is dwindling. I’m currently stuck with >80 of these that haven’t worked right since day one. They seem to be worse the higher the density mesh you have (makes sense as there’s more traffic).
I don’t have enough hubs, patience or frequency bandwidth available to try and break it down to 5 or 10 different isolated meshes… Uggghhh.
In the end, given the instability of some Zigbee implementations, it’d be good to determine how the Inovelli switches end up getting thrown into that reset state and see if there’s a more graceful way for it to be handled.