Apologies if this is hijacking the thread - I am using lots of Innr SP 242 plugs in my house in the (UK version). Would this update also be applied for this plug too?
Currently using this driver by @user3101
Apologies if this is hijacking the thread - I am using lots of Innr SP 242 plugs in my house in the (UK version). Would this update also be applied for this plug too?
Currently using this driver by @user3101
You might provide the fingerprint and driver data section screenshot for the INNR-SP242, as Mike requested above for the INNR-SP244. Then wait for his reply. But note that the above discussion was about getting the Built-in Generic Zigbee driver to reflect the correct plug numbers.
Just a few observations having run a couple of these plugs long enough to see some interesting behavior.
Side button on plug, I've noticed the reaction to pressing this on/off button doesn't always react to turning "ON" as one might expect. Sometimes it takes a depression or three, then other times it's like bam...ON, one press.
(This might have nothing to do with the outlet and more to do with some momentary mesh problem). Have a Rule that trustingly sends one OFF command to the outlet and moves on with other actions assuming that state was achieved. Today for the first time I noted the outlet did NOT go off.
Shame on me for not putting in double OFF instructions and a check & handling of the case if it did not turn off. The log shows it was told to, but it never responded that it did so...and physically it was ON when it should have gone off.
Donno if it didn't hear the HE radio or what.
EDIT ADD: I will note that I recently placed a MHCOZY relay in a box about 18" away from this outlet. So far that relay has functioned perfectly ...but might it be causing some issues if it repeats AND the outlet repeats?
Anyway, now there's two OFF commands in the Rule, second one delayed 3 seconds, and then a Conditional check to see if the outlet is indeed OFF before the rule proceeds.
Writing this up in case others observe moments of "radio deafness" or otherwise command disobedience with this INNR outlet.
Hi all, our support engineer asked me to provide some feedback in this thread on 2 questions: 1) does the SP 244 function as a repeater? and 2) what is the tx power of the SP 244? My answers are below. If you need more information please be as specific as possible about what you need.
Yes the SP 244 functions as a "repeater", i.e. it is a Zigbee router that participates in routing according to the Zigbee specification. Analyzing the routing in a mesh can be complex, especially if the tools have some known problems. A post in this forum about "zigbee-instability" provides general knowledge that might be of help.
The maximum output power of the chip used in the SP 244 is 10 dBm, which is equal to 10 mW. Some background:
In Europe, there are two restrictions on output power, namely max output power and max power spectral density. The former is 20 dBm (100 mW), but the latter effectively limits the former to a bit above 10 dBm. For more info google on 1308_HFE_eustandards.pdf, or on maximum-allowed-power-for-zigbee-applications-under-etsi-en-300-328.
In the US, the limit on max output power is 30 dBm (1 W), and I believe there is a limit on power spectral density but it doesn't further limit the max output power.
Most current Zigbee chipsets offer 10 dBm or just below it, but there are some that offer up to 20 dBm.
Hope this helps a bit.
Gerry - Innr Lighting.
Hi @PunchCardPgmr , the measuring chip in the SP 244 (BL0937) alternately measures voltage and current on 1 pin, and measures power on a separate pin. Power is not equal to voltage * current if the power factor < 1, which is the case for almost all devices nowadays. Software counts the power ticks and derives power in W and power consumption in kWh.
The SP 244 provides correct values for attributes 0x0505 (RMSVoltage), 0x0508 (RMSCurrent), and 0x050b (ActivePower) in cluster 0x0b04, and attribute 0x0000 (CurrentSummationDelivered) in cluster 0x0702. The "formatters" for those attributes are the "Multiplier" and "Divisor" attributes 0x0600 to 0x0605 of cluster 0x0b04, and the "SummationFormatting" attribute 0x0303 of cluster 0x0702.
Hope this helps fix the bug in Hubitat / driver / ...
Gerry - Innr Lighting.
I know I can speak for ALL the folks in this Community when I say THANK YOU VERY MUCH for respecting the Hubitat platform enough to step in and clarify things like this.
Over time this kind of vendor-to-vendor, vendor-to-customer communication to "get things right" will increase the endearment folks will have for your company and your device offerings.
Thanks.
cc.
@mike.maxwell at Hubitat
Hi Gerry, thank you very much for responding here. I had been communicating with one of your tech support folks on this (Florian) and I suggested that Innr post the information here in this thread for everyone to see. Really appreciate you taking the time so the community can all benefit from your answers.