Innr SP-242 Smart Plug not reporting status automatically

davmc123 commented 8 months ago

The device support recently added in PR: Add device support for: Innr SP-242 Smart Plug #6703, does not seem to be reporting status information and sensor readings automatically. They only update when the 'Refresh' buttons are pressed in the Z2M 'Exposes' tab. This includes switch 'State', 'Power', 'Voltage' and 'Current'.

If I press the 'Apply' button for each item listed in the 'Reporting' settings menu, the smart plug will start reporting the sensors automatically, one by one.

If the smart plug is unplugged and plugged in again (power cycled) it stops reporting automatically. Pressing the 'Apply' button again for each item allows the automatic reporting to continue.

Smart Plug Info

Zigbee Model	SP 242
Firmware build date	20231019
Firmware version	1.4.3

Zigbee2MQTT Info

Zigbee2MQTT Bridge Coordinator Version	6.10.3.0 build 297
Zigbee2MQTT Bridge Version	1.34.0-dev

GerryInnr commented 4 months ago

Hi guys, we're discussing at Innr how to provide a solution to you (in the form of a firmware upgrade) for the overvoltage protection issue, give us a few days to get back to you here. For the issue of attribute reporting stopping after power cycle, we need support from the SDK supplier, which is taking longer than hoped for.

thebatfink commented 4 months ago

Thanks for the feedback, hopefully can get these plugs working well. Interested to find out what solution you come up with.

GerryInnr commented 4 months ago

Hello again. Sorry it took a while to get back to you. I sent firmware updates for the SP 240, SP 242, and SP 244 to Koen for release on zigbee2mqtt. The new version is 1.6.22. Release notes:

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.

We believe the relaxed overload limits will fix most if not all undesired activations of the overload protection mechanism. Still, we would like to ask your opinion on whether more control is desirable. We checked available standard Zigbee functionality for ways in which the limits can be user-defined, or in which the overload protection mechanism could be switched off. For defining limits/thresholds, there are attributes in the Electrical Measurement cluster, the Power Configuration cluster, and the Metering cluster. However, the definition of all those attributes is coupled to the Alarms cluster, and to use those attributes in a Zigbee compliant manner implies implementing the Alarms cluster and generating alarms when thresholds are crossed, not switching off a relay. The Electrical Measurement cluster also contains an "ACAlarmsMask" attribute to enable/disable alarms, but the same remark applies. We prefer not to abuse standard attributes for purposes for which they were not defined.

We see three alternatives:

Add one or more manufacturer-specific attributes to an existing cluster, or in a manufacturer-specific cluster, that allow enabling/disabling the undervoltage, overvoltage, and overcurrent protection. Perhaps some manufacturer has already done this and zigbee2mqtt already supports these?
Add one or more manufacturer-specific attributes to an existing cluster, or in a manufacturer-specific cluster, that allow setting the thresholds for undervoltage, overvoltage, and overcurrent. Same question.
Allowing the user to disable (and enable again) the overload protection by means of a button sequence, for example press-and-hold the button between 15 and 20 seconds and release. When the protection is disabled, this could be indicated for example by having the LED blink once at every on/off action.

Our preference goes to option 3; it's easy to implement and can be used by everyone without needing additional support in the rest of the system. But we would like to hear your opinion.

One last remark: people that measure a voltage in their homes that is structurally significantly higher than the nominal 230 V / 120 V, run an increased risk of having a lower device lifetime. The organisation/company that supplies the electricity to your home can be requested to investigate and correct.

thebatfink commented 4 months ago

Personally I like option 3 to be able to turn it off. I didnt personally get the devices for the protection element (and didnt know it even existed until this problem occurred) and otherwise, my devices would go directly to the mains sockets anyway. Assuming it isn’t for the innr devices themselves that this protection exists because they have some specific tolerance to voltage that can’t be exceeded. I haven’t come across this personally on any other plug I’ve had. Ultimately I just dont want the plug to turn off unless I tell it to. If there is an issue in my mains I expect the consumer box to handle it and throw fuses.

thebatfink commented 4 months ago

Anyone know how we get this firmware onto our devices? I don’t even see the plugs in OTA.

leander091 commented 4 months ago

Anyone know how we get this firmware onto our devices? I don’t even see the plugs in OTA.

The firmware has been uploaded to the OTA repo. But the device has not yet the OTA capability exposed. Will create a PR to add this support

digital-cowboy-91 commented 4 months ago

I decided to keep the switches as I've seen Innr have entered this topic. Yesterday I did the update and so far so good, thanks @GerryInnr . I can't see any drop in voltage, this seems to be reported as before, but I can confirm that switch did not power cycle at high peaks, which is usually during 11PM and 3AM. Now I am about to update the second switch - this one has reported two anomalies at night (200V and 254V) even though its connected to the same power socket as the first one. Probably will turned them on together at high peak tonight to see if the update really helped. Thanks again!

basrieter commented 4 months ago

Did you OTA them?

digital-cowboy-91 commented 4 months ago

Yes

basrieter commented 4 months ago

Via Zigbee2mqtt?

digital-cowboy-91 commented 4 months ago

One via Z2M, second I am about to update now via ZHA, but it's constantly loosing connection. Via Z2M it was definitely smoother.

Edit: I should have mention that I had to enable OTA on them first . As per Koenk git, the firmware itself has been merged to main branch which is great, however the converter itself is missing ota: ota.zigbeeOTA . So I've entered node_modules in Z2M and updated the converter manually.

@basrieter

basrieter commented 4 months ago

For me the device is not appearing in the OTA list. Running the latest stable Z2M.

Picard16 commented 4 months ago

For me the device is not appearing in the OTA list. Running the latest stable Z2M.

I'm also waiting for them to appear in the zigbee2mqtt OTA list. As far as I understood @leander091 made a PR for it, right?

leander091 commented 4 months ago

For me the device is not appearing in the OTA list. Running the latest stable Z2M.

I'm also waiting for them to appear in the zigbee2mqtt OTA list. As far as I understood @leander091 made a PR for it, right?

Sorry, I was busy with real life last weekend so was not able to finish my PR. Created a draft PR Here: but will test it first with one of my plugs before marking it final

leander091 commented 4 months ago

Support for updating these plugs has been merged into the Zigbee2mqtt development branch. In a few hours everyone running the dev version will see the OTA capability. After the official release the rest of the users could enjoy this as well. :)

Picard16 commented 4 months ago

That's great @leander091! I really appreciate your help in this case. I didn't want to exert any pressure or even complain with my last post. Thank you very much. 💐 I'm curious to see how the update works in zigbee2mqtt (never done before) and, above all, whether my Innr SP-240 plugs behave better and are more stable.

thebatfink commented 4 months ago

I do hope they enable some functionality to turn it off completely though. I’m nervous now having it on anything which needs power 24/7. I dont know about others but I dont buy these plugs for on and off remote switching as much as individual device power consumption monitoring. Those inevitably are the devices which are on 24/7 consuming most power. Not ideal when the device your monitoring is attached to the zigbee coordinator machine and it keeps turning itself off.

I think we are still waiting for the changes on the messaging side though right? i.e. we still need to manually poll for attribute updates.

thebatfink commented 4 months ago

Support for updating these plugs has been merged into the Zigbee2mqtt development branch. In a few hours everyone running the dev version will see the OTA capability. After the official release the rest of the users could enjoy this as well. :)

I noticed this was added in latest non dev release a couple of days ago but it doesn’t work for me. I also tried removing and force removing the devices and pairing them back up and still they don’t show in the OTA? The external convertor file above for manually polling the devices isn’t causing some issue / needs some modification as well does it?

leander091 commented 4 months ago

Support for updating these plugs has been merged into the Zigbee2mqtt development branch. In a few hours everyone running the dev version will see the OTA capability. After the official release the rest of the users could enjoy this as well. :)

I noticed this was added in latest non dev release a couple of days ago but it doesn’t work for me. I also tried removing and force removing the devices and pairing them back up and still they don’t show in the OTA? The external convertor file above for manually polling the devices isn’t causing some issue / needs some modification as well does it?

Could you try with the external converter disabled? I think the external converter will take precedence above the default configuration for Innr devices

thebatfink commented 4 months ago

Yes its the external convertor. I guess disable, update and then re-enable will work as a workaround until the reporting is fixed by innr in the firmware.

Maxdola commented 4 months ago

Hi there, I was able to do the firmware update without changing anything, but unfortunately the accumulated power is still not reporting automatically. Does anyone know what I need to do ?

thebatfink commented 4 months ago

Scroll up to trinodes post with the code to drop in a file in the z2m folder. It polls the device every 60 seconds to get updated values. Failing that we are still waiting for innr to fix it.

Maxdola commented 4 months ago

I wonder if they are shutting off because of sensed over voltage like Whimsy says. Mine was reporting up at 252.. What voltage are yours reporting? Are they getting up this high?

I did that, (I am using Z2M as the HA addon), but it still isn't working. But also how do I event know if my external definition is used ? So I don't know if I did something wrong on the way.

thebatfink commented 4 months ago

Did you put the external convertors entry in z2m configuration.xaml? You’ll know now because they’ll disappear out the OTA, and of course you can sit and watch one of the entities in HA UI updating every 60 secs, or look at z2m logs to see the messages coming every 60 secs. It definitely works. I’m also home assistant with z2m addon, its not that.

Maxdola commented 4 months ago

Did you put the external convertors entry in z2m configuration.xaml? You’ll know now because they’ll disappear out the OTA, and of course you can sit and watch one of the entities in HA UI updating every 60 secs, or look at z2m logs to see the messages coming every 60 secs. It definitely works. I’m also home assistant with z2m addon, its not that.

Ok, then I did something wrong because I still see them in the OTA tab.

This is my folder structure:

my config (partial):

thebatfink commented 4 months ago

Have you restarted z2m addon?

Maxdola commented 4 months ago

Have you restarted z2m addon?

Yes and I even just restarted HA.

Maxdola commented 4 months ago

OK, it was my fault. I overlooked, that I am from Germany and I have the SP240. I just overlooked the 2 at the end. So thank you very much for the support and the script it now works perfectly :).

Picard16 commented 4 months ago

Yes its the external convertor. I guess disable, update and then re-enable will work as a workaround until the reporting is fixed by innr in the firmware.

Or you can add: "ota: ota.zigbeeOTA"

in the SP240.js (or SP242.js) file, then the devices appear in the OTA list again

davmc123 commented 3 months ago

Yes its the external convertor. I guess disable, update and then re-enable will work as a workaround until the reporting is fixed by innr in the firmware.

Or you can add: "ota: ota.zigbeeOTA"

in the SP240.js (or SP242.js) file, then the devices appear in the OTA list again

Did you add something else in? The converter fails to load when I add that in to my file with the following error:

[2024-05-13 22:05:12] error:    z2m: Failed to load external converter file 'SP242.js' (ota is not defined)
[2024-05-13 22:05:12] error:    z2m: Probably there is a syntax error in the file or the external converter is not compatible with the current Zigbee2MQTT version

Picard16 commented 3 months ago

Yes its the external convertor. I guess disable, update and then re-enable will work as a workaround until the reporting is fixed by innr in the firmware.

Or you can add: "ota: ota.zigbeeOTA" in the SP240.js (or SP242.js) file, then the devices appear in the OTA list again

Did you add something else in? The converter fails to load when I add that in to my file with the following error:
[2024-05-13 22:05:12] error:  z2m: Failed to load external converter file 'SP242.js' (ota is not defined)
[2024-05-13 22:05:12] error:  z2m: Probably there is a syntax error in the file or the external converter is not compatible with the current Zigbee2MQTT version

No, I only added the line above line in my SP240.js file (which is a slightly edited copy of the given file above) and the OTA-line(s) appeared again. Here is my complete js-file: SP240.txt

Update 2024-05-18: I saw that I also got your second mentioned error message (syntax error). Because I am not familiar enough with coding to find the problem, I deactivated the external converter SP240.js again. 🤷

kingtheydon commented 3 months ago

To answer my own question, while we wait for a firmware update we can update the configuration to use polling to update the stats regularly (every 60s by default):

I've stolen the method the tuya plugs with the same issue use, and inlined it in this definition so it won't break if the tuya method is modified / removed.

As per that implementation there's a field called Measurement poll interval to set the number of seconds between stat updates.

Definition file:-

SP242.js

const {onOff, electricityMeter} = require('zigbee-herdsman-converters/lib/modernExtend');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const globalStore = require('zigbee-herdsman-converters/lib/store');
const utils = require('zigbee-herdsman-converters/lib/utils');
const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const e = exposes.presets;
const ea = exposes.access;

async function onEventMeasurementPoll(type, data, device, options,
    electricalMeasurement=true, metering=false) {
    const endpoint = device.getEndpoint(1);
    if (type === 'stop') {
        clearTimeout(globalStore.getValue(device, 'measurement_poll'));
        globalStore.clearValue(device, 'measurement_poll');
    } else if (!globalStore.hasValue(device, 'measurement_poll')) {
        const seconds = utils.toNumber(
            options && options.measurement_poll_interval ? options.measurement_poll_interval : 60, 'measurement_poll_interval');
        if (seconds === -1) return;
        const setTimer = () => {
            const timer = setTimeout(async () => {
                try {
                    if (electricalMeasurement) {
                        await endpoint.read('haElectricalMeasurement', ['rmsVoltage', 'rmsCurrent', 'activePower']);
                    }
                } catch (error) {/* Do nothing*/}
                try {
                    if (metering) {
                        await endpoint.read('seMetering', ['currentSummDelivered']);
                    }
                } catch (error) {/* Do nothing*/}
                setTimer();
            }, seconds * 1000);
            globalStore.putValue(device, 'measurement_poll', timer);
        };
        setTimer();
    }
}

const definition = {
    zigbeeModel: ['SP 242'],
    model: 'SP 242',
    vendor: 'Innr',
    description: 'Automatically generated definition',
    extend: [onOff({"powerOnBehavior":false}), electricityMeter({current: {divisor: 1000}, voltage: {divisor: 1}, power: {divisor: 1}, energy: {divisor: 100}})],
    meta: {},
    options: [exposes.options.measurement_poll_interval()],
    onEvent: (type, data, device, options) =>
        onEventMeasurementPoll(type, data, device, options,
            true, // polling for voltage, current and power
            true, // polling for energy
        ),

};

module.exports = definition;

add the file as an external definition in the configuration.yaml file:-

external_converters:
  - SP242.js

Bit of a noob question with the above apologies!

So how and where do I create this sp242.js file?

I use studio server for messing with configuration files etc (don't do it often though) and struggling to understand where that file goes

Cheers

p-paule commented 3 months ago

I'm having trouble to update my SP-240 to innr_controlleddevice-sp240-1.6.22.ota via ZHA. Any ideas how I could solve this? Thanks for the help!

Core 2024.5.5 Supervisor 2024.05.2 Operating System 12.3 on Homeassistant Green with SkyConnect

I have configured OTA as follows in configuration.yaml:

zha:
   zigpy_config:
     ota:
       ikea_provider: true                        # Auto update Trådfri devices
       ledvance_provider: true                    # Auto update LEDVANCE/OSRAM devices
       salus_provider: true                       # Auto update SALUS/Computime devices
       inovelli_provider: true                    # Auto update INOVELLI devices
       thirdreality_provider: true                # Auto update 3REALITY devices
       allow_file_providers: "I understand I can *destroy* my devices by enabling OTA updates from files. Some OTA updates can be mistakenly applied to the wrong device, breaking it. I am consciously using this at my own risk."
       otau_directory: /config/zigpy_ota        # Utilize .ota files to update everything else

And put innr_controlleddevice-sp240-1.6.22.ota in /config/zigpy_ota. However I'm missing a "[zigpy.ota.provider] ImageKey ..." in the log, I only get:

2024-05-26 14:43:37.624 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Trådfri object at 0xffff5fab2840>
2024-05-26 14:43:37.627 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Inovelli object at 0xffff5e75c680>
2024-05-26 14:43:37.630 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Ledvance object at 0xffff5fa43c20>
2024-05-26 14:43:37.633 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Salus object at 0xffff6043c860>
2024-05-26 14:43:37.636 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Sonoff object at 0xffff5e92f290>
2024-05-26 14:43:37.640 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.ThirdReality object at 0xffff5e8d32c0>
2024-05-26 14:43:40.201 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Trådfri object at 0xffff5e572150>
2024-05-26 14:43:40.202 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Inovelli object at 0xffff5e572270>
2024-05-26 14:43:40.202 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Ledvance object at 0xffff5da27f80>
2024-05-26 14:43:40.203 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Salus object at 0xffff5da27ef0>
2024-05-26 14:43:40.203 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.Sonoff object at 0xffff5da27b90>
2024-05-26 14:43:40.203 DEBUG (MainThread) [zigpy.ota] Registering new OTA provider: <zigpy.ota.providers.ThirdReality object at 0xffff5da27b60>

When issuing

service: zha.issue_zigbee_cluster_command
data:
  cluster_type: out
  ieee: xxx
  endpoint_id: 1
  command_type: client
  cluster_id: 25
  command: 0
  params:
    payload_type: 0
    query_jitter: 100

I get the following in the log:

2024-05-26 14:45:16.905 DEBUG (MainThread) [zigpy.ota] No new firmware is compatible with the device or the device is already fully up-to-date

Please note that the firmware update via zha-toolkit is currently broken, so I cannot go that route.

p-paule commented 3 months ago

I found the following solution in the meantime: I removed otau_directory and added

  zigpy_config:
    ota:
      z2m_remote_index: https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/index.json

As described here.

Then the image_notify command (issued via the GUI or Developer Tools) will work and the GUI offers me the firmware update for installation.

With the following config it will automatically issue the image_notify command and show the updates in the GUI:

zha:
  zigpy_config:
    ota:
      # Periodically send out a network-wide (including end devices!) image notification
      broadcast_enabled: true
      broadcast_initial_delay: 14400
      broadcast_interval: 14400

      ikea_provider: true                        # Auto update Trådfri devices
      ledvance_provider: true                    # Auto update LEDVANCE/OSRAM devices
      salus_provider: true                       # Auto update SALUS/Computime devices
      inovelli_provider: true                    # Auto update INOVELLI devices
      thirdreality_provider: true                # Auto update 3REALITY devices
      z2m_remote_index: https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/index.json

weljajoh commented 3 months ago

Yes its the external convertor. I guess disable, update and then re-enable will work as a workaround until the reporting is fixed by innr in the firmware.

Or you can add: "ota: ota.zigbeeOTA" in the SP240.js (or SP242.js) file, then the devices appear in the OTA list again

Did you add something else in? The converter fails to load when I add that in to my file with the following error:
[2024-05-13 22:05:12] error:  z2m: Failed to load external converter file 'SP242.js' (ota is not defined)
[2024-05-13 22:05:12] error:  z2m: Probably there is a syntax error in the file or the external converter is not compatible with the current Zigbee2MQTT version

You also need to add the definition for ota to your .js file:

[...]
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const ota = require('zigbee-herdsman-converters/lib/ota');
const e = exposes.presets;
[...]

thebatfink commented 3 months ago

Hello again. Sorry it took a while to get back to you. I sent firmware updates for the SP 240, SP 242, and SP 244 to Koen for release on zigbee2mqtt. The new version is 1.6.22. Release notes:

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.

We believe the relaxed overload limits will fix most if not all undesired activations of the overload protection mechanism. Still, we would like to ask your opinion on whether more control is desirable. We checked available standard Zigbee functionality for ways in which the limits can be user-defined, or in which the overload protection mechanism could be switched off. For defining limits/thresholds, there are attributes in the Electrical Measurement cluster, the Power Configuration cluster, and the Metering cluster. However, the definition of all those attributes is coupled to the Alarms cluster, and to use those attributes in a Zigbee compliant manner implies implementing the Alarms cluster and generating alarms when thresholds are crossed, not switching off a relay. The Electrical Measurement cluster also contains an "ACAlarmsMask" attribute to enable/disable alarms, but the same remark applies. We prefer not to abuse standard attributes for purposes for which they were not defined.

We see three alternatives:

Add one or more manufacturer-specific attributes to an existing cluster, or in a manufacturer-specific cluster, that allow enabling/disabling the undervoltage, overvoltage, and overcurrent protection. Perhaps some manufacturer has already done this and zigbee2mqtt already supports these?

Add one or more manufacturer-specific attributes to an existing cluster, or in a manufacturer-specific cluster, that allow setting the thresholds for undervoltage, overvoltage, and overcurrent. Same question.

Allowing the user to disable (and enable again) the overload protection by means of a button sequence, for example press-and-hold the button between 15 and 20 seconds and release. When the protection is disabled, this could be indicated for example by having the LED blink once at every on/off action.

Our preference goes to option 3; it's easy to implement and can be used by everyone without needing additional support in the rest of the system. But we would like to hear your opinion.

One last remark: people that measure a voltage in their homes that is structurally significantly higher than the nominal 230 V / 120 V, run an increased risk of having a lower device lifetime. The organisation/company that supplies the electricity to your home can be requested to investigate and correct.

@GerryInnr Any update on the stats not getting reported fix and an option to disable the over volt protection?

SimeJah commented 2 months ago

I have an SP240 but your script works like a charm after a few adaptions.

Thanks

Can you please share your tweaks on it and how you made it work? I have the SP240's aswell with the same issue.

Maxdola commented 2 months ago

I have an SP240 but your script works like a charm after a few adaptions. Thanks

Can you please share your tweaks on it and how you made it work? I have the SP240's aswell with the same issue.

I have SP240 as well and you just need to change the SP242 to SP240 everywhere that's it.

SimeJah commented 2 months ago

I have an SP240 but your script works like a charm after a few adaptions. Thanks

Can you please share your tweaks on it and how you made it work? I have the SP240's aswell with the same issue.

I have SP240 as well and you just need to change the SP242 to SP240 everywhere that's it.

Thanks! I thought this script was an extension to be loaded in Z2MQTT but I get 'ConstructorClass is not a constructor'. How do I implement this fix?

SimeJah commented 2 months ago

nvm.. Hitting apply in the report section in the z2mqtt frontend did the trick :)

GerryInnr commented 2 months ago

@GerryInnr Any update on the stats not getting reported fix and an option to disable the over volt protection?

Hello, @thebatfink yes I can finally give you some good news. A new firmware version 1.7.22 (OTA File Version 0x17163685) will be available soon 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.

Note: @Koenkk already uploaded version 1.7.20, but that version does not disable the voltage overload protection in most cases.

If you experience any issues with version 1.7.22, please let me know.

Koenkk commented 2 months ago

OTAs are available now (added in https://github.com/Koenkk/zigbee-OTA/pull/512)

thebatfink commented 2 months ago

So whats the procedure here to get this working? I disabled the external convertor which was doing the polling. Removed the device. Rejoined the device. Updated to 1.7.22 and now back to nothing updating unless manually refreshing in z2m gui (edit, energy just hadn’t ticked over to 0.1 yet, value is now returned). But nothing seems to automatically update.

Maybe I am a bit hasty, I tested on a plug with a very stable small load. Some things are updating slowly, maybe I try on something with more variable load.

thebatfink commented 2 months ago

Curious what others are finding. I don’t feel like power and energy are updating properly. Current and voltage seem better (albeit less frequently than other plugs I have).

GerryInnr commented 2 months ago

@thebatfink the plug reports as requested from it by the bridge (or any other device). To receive attribute reports for voltage, current, power, and power consumption, the bridge must:

create bindings to clusters 0x0b04 (Electrical Measurement) and 0x0702 (Metering) on the plug
configure attribute reporting for attributes 0x0505 (RMSVoltage), 0x0508 (RMSCurrent), and 0x050b (ActivePower) in cluster 0x0b04, and attribute 0x0000 (CurrentSummationDelivered) in cluster 0x0702.

With the ConfigureAttributeReporting command, the bridge can define the minimum reporting interval, the maximum reporting interval, and the "reportable change", for every attribute individually:

reportable change: plug reports when there is a change >= this value since the last report
minimum interval: plug will not report more frequently than this
maximum interval: plug will send a report after this time even if there was no change.

So it depends on what the bridge configures, how fast the plug will report. You can let it report every second (wouldn't recommend that in a large network with many plugs). Also, in general, choose the reportable change value wisely as it can lead to multiple reports per second if set too small.

Hope this helps.

thebatfink commented 2 months ago

Yes, I noticed eventually the default reporting values were quite different by default to my other plugs. I matched them up and so far seems working well. I haven’t yet tried the voltage protection disabling but looks good on reporting side. Shame they weren’t working nicely out the box, but thanks for engaging and getting these going good now. Think I’ll invest in a few more plugs now they are working well.

netcruiser2k10 commented 1 month ago

I have recently updated my Innr sp242 to the newest firmware and it is not updating the energy value even after removing and readding the plug to MQTT. I have inplemented the external converter above to enable polling to update the energy value for me. all the other figures like watts and voltage seem to be updating as they should just the Energy isnt. Can anyone help me with creating the bindings @GerryInnr suggested above in z2mqtt. I'll get using the external converter listed at the start of this thread for now.

thebatfink commented 1 month ago

Did you read the last few posts, it is only updating when there is something to update, you can change the settings to set lower maximum update durations.

marbon87 commented 1 month ago

@thebatfink the plug reports as requested from it by the bridge (or any other device). To receive attribute reports for voltage, current, power, and power consumption, the bridge must:

create bindings to clusters 0x0b04 (Electrical Measurement) and 0x0702 (Metering) on the plug

configure attribute reporting for attributes 0x0505 (RMSVoltage), 0x0508 (RMSCurrent), and 0x050b (ActivePower) in cluster 0x0b04, and attribute 0x0000 (CurrentSummationDelivered) in cluster 0x0702.

With the ConfigureAttributeReporting command, the bridge can define the minimum reporting interval, the maximum reporting interval, and the "reportable change", for every attribute individually:

reportable change: plug reports when there is a change >= this value since the last report

minimum interval: plug will not report more frequently than this

maximum interval: plug will send a report after this time even if there was no change.

So it depends on what the bridge configures, how fast the plug will report. You can let it report every second (wouldn't recommend that in a large network with many plugs). Also, in general, choose the reportable change value wisely as it can lead to multiple reports per second if set too small.

Hope this helps.

can someone tell me how i do this in home assistant? I have two sps-242 with the latest firmware. One is updating the value regularly and the other one does not after i trief to configred it.

thebatfink commented 1 month ago

Load up the z2m gui from Settings -> Addons -> Z2M -> Open WebUI.

In the devices list, find you device and go into it clicking the name. In the device details goto the Reporting tab. There you have min/max reporting intervals and minimum reporting change values on the end for each parameter. Change one, click apply corresponding to that row.

But bear in mind just because one updates and another doesn’t, maybe one just doesn’t have any change to report. They’ll only change as frequently as each other if the devices connected to them are pulling the same amount of energy out the wall (assuming this Reporting tab shows the same configuration variables in each device). If you have an LED bulb in one and the other has a washing machine connected to it, the one with the bulb isn’t going to update as frequently anyway.

Not suggesting these are ideal settings or anything but for an idea, I have all my parameters for min report interval as 5 except onoff 0, max report interval as 3600. Min rep change I set power and voltage to 5, current to 50, sumdelivered 500 and onoff 1. I took these from the default values from another brand of plug I had in my network. Find them OK for my automation needs. I assume the intervals are in minutes because for sure if they were seconds, my devices aren’t reporting every 60 minutes.

Koenkk / zigbee-herdsman-converters

Innr SP-242 Smart Plug not reporting status automatically #6747

Smart Plug Info

Zigbee2MQTT Info