Recently bought some INNR 242 outlets (UK specific) and was seeing some problems where the power would cut out and then turn back on again. I have been living with it as is infrequent but then I came across this thread a couple of days ago:
This acknowledges that there is a known problem where the outlets turn themselves off due to some built in circuit protection (towards bottom of thread). Literally within minutes of me finding the post a solution was presented with a new firmware update. I wish all technical problems were resolved like that!
From what I can tell for Zigbee firmware updates I need these to be loaded by Hubitat staff so that the app can access them. Is this correct, how do I make it happen? There is a link to the new firmware posted on the thread.
You know, this is not the only one.
Some of my Zooz Z-Wave power monitoring plugs do the same.
Sometimes, there will be an erroneous reading which will make the device think it's overloaded, so it shuts itself down.
One of the Zooz plugs allows you to turn off this self protection feature; I feel all plugs should have this option.
I don't know how INNR's firmware revision works, but it's probably hard to filter out the erroneous readings internally.
For the Zooz plugs, @jtp10181 's driver filters out erroneous readings to the Hub, but internal erroneous readings that trigger a device self-protective shutdown, like current (amps), I believe, still occur.
Also, another reason to not get a power monitoring plug: this is what circuit breakers are for.
edit: They're getting too fancy for their own good.
They said they increased the threshold by 3% which should remove all but the most extreme instances. Mine seem to trigger when the sun comes out and so suspect the solar/battery is causing the overload. Lets see if the firmware does the job.
Ahh, excellent. Would be good if the team could make this firmware available through HE - i have just come across this myself, and was wondering what to do next!
I know @mike.maxwell has gotten f/w files from Innr in the past (for the 224 and 234 plugs), so hopefully he can get any available updates for these 24x plugs.
@Gerry-Innr I don't suppose you are able to assist here, as well? Is there a means to get firmware across to the folks at Hubitat so we can update the Innr devices without having to switch to another platform and back again?
I wonder if this is related to often observing anywhere from 1-4 depressions of the manual on/off button on the side of the plug to get it to go on.
There's an AC unit with as much as a 4.8amp load but I doubt is all kicking in the second that button is pressed. That said, the button doesn't even light up...so it doesn't seeeeem like it tries to pass the load and then drops it. But who knows, maybe it sees the surge mounting and denies it.
Hi jason12, I'd be happy to send any firmware updates to a Hubitat developer or release manager so they can be rolled out via Hubitat. If someone can give me contact details we'll arrange it.
I saw that above version 1.6.22 was mentioned. That version has the following changes w.r.t. version 1.4.3:
The limits for the overload protection feature have been stretched by 3% to account for the worst-case deviation of the measurement chip, as follows:
SP 240 (EU): undervoltage went from 176 V to 167 V, overvoltage from 253 V to 261 V, and overcurrent from 16800 mA to 17304 mA.
SP 242 (UK): undervoltage went from 176 V to 167 V, overvoltage from 253 V to 261 V, and overcurrent from 13700 mA to 14060 mA.
SP 244 (US): undervoltage went from 96 V to 87 V, overvoltage from 132 V to 136 V, and overcurrent from 16000 mA to 16223 mA.
Scene table format fixed. NB: due to a change in the SDK in the scene table format, after an update from version 1.4.3 to this version, the device will lose all its Zigbee scenes. Zigbee groups are unaffected.
Sorry we couldn't help the loss of scenes, the SDK did not provide enough handles to convert them.
There is a newer version 1.7.22 with the following changes:
Fixed attribute reporting not working after power cycle; binding table is now persisted.
Attribute 0x0000 CurrentSummationDelivered of the Metering cluster 0x0702 was mentioned by some as not reporting, but our testing showed the attribute is reported if requested: interested devices (such as a bridge) must create a binding to cluster 0x0702 and send command ConfigureAttributeReporting for the attribute. The binding is now also persisted so it keeps working after a power cycle.
Added possibility to disable voltage over/underload protection:
Keep button pressed between 15 and 20 seconds, then release. After 5 seconds, the LED will start quick-blinking; keep the button pressed. After 10 seconds, blinking stops; keep the button pressed. After 15 seconds, the LED will start quick-blinking again. Now release the button. The LED will slow-blink twice to indicate success. Every on/off action, local with the button or by remote command, will now double-blink the LED before assuming final state; this to indicate that the voltage over/underload protection is disabled. Enable again in the same way. Enabled/disabled state is persisted over power-cycles, even if not paired to a bridge. Note that the current overload protection will remain active.
And then there is version 1.7.23 with a minor fix:
When the smart plug is not paired to a network, power-cycling it always turned it on. This fix corrects that issue, the plug now always assumes its last state when power-cycled (unless it is in a network and a client device changes the behavior by setting the StartUpOnOff attribute).
Hi PunchCardPgmr, the firmware update might improve the button handling (there were some improvements in the SDK regarding GPIO handling), but since the button also doesn't light up, it looks more like a faulty device. If the firmware update doesn't help, I recommend contacting our service dept. to get the plug replaced.
Hi Jim, was the change in 1.6.22 sufficient to prevent the overload protection kicking in when it shouldn't, or did you have to manually disable the feature with version 1.7.22?
Hi velvetfoot, a circuitbreaker is relatively slow if it's not a complete shortcircuit, and it won't trip at all if its current rating (which may be higher than the smart plug's rating) is not superceded. We believe that having a resettable overload protection feature in the smart plug helps prevent broken smart plugs (they also contain a non-resettable overload protection in the form of a fuse / fusible resistor) and broken devices.
Hey Gerry, I am still waiting for the firmware to be made available via HE as do not have any other way to update, The devices are not in use at present as cause too much frustration.
But, thanks for the bump on this thread, it looks like you got the attention of @mike.maxwell so I am hopeful this will be in a future release.
Unfortunately, as I've said, it has been my experience with other brand Z-wave switches that erroneous internal current reporting can shut down a plug for no good reason. Maybe it doesn't happen with yours, but it sounds like it does. Falsely shutting something down can have undesired effects.
