After configuration of a Ubisys Device i get a `(Status 'INSUFFICIENT_SPACE')`

[Danit2]

What happened?

When i want to configure the input_action of a Ubisys Device i get an error when the system will read back the configuration from the device. Sometimes z2m also crash. The new configuration will work. So the command to change the input_action will work but only the read back make the problem.

When i only read back the configuration with: zigbee2mqtt/FRIENDLY_NAME/get/configure_device_setup i get this error:

'Error: Read 0x001fee0000007b93/232 manuSpecificUbisysDeviceSetup(["inputConfigurations","inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')'

When i want to set a new configuration i get the same error but z2m will crash with this error:

Error: Read 0x001fee0000008d0d/232 manuSpecificUbisysDeviceSetup(["inputConfigurations","inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')
    at Endpoint.checkStatus (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:317:28)
    at Endpoint.read (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:480:22)
    at Object.convertGet (/app/node_modules/zigbee-herdsman-converters/devices/ubisys.js:519:17)

I have try this with multible devices like a d1, c4 und s2. On every device the same error.

@sjorge can you help with this? Do you have the same error?

I don't know when this problem came. but befor a half year i did this the last time and it was working without problem.

Thanks.

What did you expect to happen?

That this will work without a error.

How to reproduce it (minimal and precise)

Change the input_action of a Ubisys device or try to read them back.

Zigbee2MQTT version

1.29.0

Adapter firmware version

20220726

Adapter

Sonoff Dongle P

Debug log

No response

[sjorge]

Reading from an S1

mosquitto_pub -t zigbee2mqtt/switch/pantry/light/get/configure_device_setup -m ''

debug 2023-01-02 13:18:49: Received MQTT message on 'zigbee2mqtt/switch/pantry/light/get/configure_device_setup' with data ''
debug 2023-01-02 13:18:49: Publishing get 'get' 'configure_device_setup' to 'switch/pantry/light'
debug 2023-01-02 13:18:50: Received Zigbee message from 'switch/pantry/light', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputActions":[{"data":[0,7,2,6,0,2],"type":"Buffer"},{"data":[0,134,2,8,0,5,0,50],"type":"Buffer"},{"data":[0,198,2,8,0,5,1,50],"type":"Buffer"},{"data":[0,11,2,8,0,3],"type":"Buffer"}],"inputConfigurations":[0]}' from endpoint 232 with groupID 0
info  2023-01-02 13:18:50: MQTT publish: topic 'zigbee2mqtt/switch/pantry/light', payload '{"configure_device_setup":{"input_actions":[[0,7,2,6,0,2],[0,134,2,8,0,5,0,50],[0,198,2,8,0,5,1,50],[0,11,2,8,0,3]],"input_configurations":[0]},"energy":0.1,"linkquality":109,"power":0,"power_on_behavior":"on","state":"ON","update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}'

Reading from an S2

mosquitto_pub -t zigbee2mqtt/switch/kitchen/light/get/configure_device_setup -m ''

debug 2023-01-02 13:21:22: Received MQTT message on 'zigbee2mqtt/switch/kitchen/light/get/configure_device_setup' with data ''
debug 2023-01-02 13:21:22: Publishing get 'get' 'configure_device_setup' to 'switch/kitchen/light'
debug 2023-01-02 13:21:22: Received Zigbee message from 'switch/kitchen/light', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputConfigurations":[0,0]}' from endpoint 232 with groupID 0
error 2023-01-02 13:21:22: Publish 'get' 'configure_device_setup' to 'switch/kitchen/light' failed: 'Error: Read 0x001fee000000594d/232 manuSpecificUbisysDeviceSetup(["inputConfigurations","inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')'
debug 2023-01-02 13:21:22: Error: Read 0x001fee000000594d/232 manuSpecificUbisysDeviceSetup(["inputConfigurations","inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')
    at Endpoint.checkStatus (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:317:28)
    at Endpoint.read (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:480:22)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at Object.convertGet (/opt/zigbee2mqtt/node_modules/zigbee-herdsman-converters/devices/ubisys.js:519:17)
    at Publish.onMQTTMessage (/opt/zigbee2mqtt/lib/extension/publish.ts:273:21)

Reading from an C4

mosquitto_pub -t zigbee2mqtt/switch/livingroom/light_bottom/get/configure_device_setup -m ''

debug 2023-01-02 13:22:41: Received MQTT message on 'zigbee2mqtt/switch/livingroom/light_bottom/get/configure_device_setup' with data ''
debug 2023-01-02 13:22:41: Publishing get 'get' 'configure_device_setup' to 'switch/livingroom/light_bottom'
debug 2023-01-02 13:22:41: Received Zigbee message from 'switch/livingroom/light_bottom', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputConfigurations":[0,0,0,0]}' from endpoint 232 with groupID 0
error 2023-01-02 13:22:41: Publish 'get' 'configure_device_setup' to 'switch/livingroom/light_bottom' failed: 'Error: Read 0x001fee0000005baa/232 manuSpecificUbisysDeviceSetup(["inputConfigurations","inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')'
debug 2023-01-02 13:22:41: Error: Read 0x001fee0000005baa/232 manuSpecificUbisysDeviceSetup(["inputConfigurations","inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')
    at Endpoint.checkStatus (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:317:28)
    at Endpoint.read (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:480:22)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at Object.convertGet (/opt/zigbee2mqtt/node_modules/zigbee-herdsman-converters/devices/ubisys.js:519:17)
    at Publish.onMQTTMessage (/opt/zigbee2mqtt/lib/extension/publish.ts:273:21)
info  2023-01-02 13:22:41: MQTT publish: topic 'zigbee2mqtt/switch/livingroom/light_bottom', payload '{"configure_device_setup":{"input_configurations":[0,0,0,0]},"linkquality":98,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}'

@Koenkk any idea where this INSUFFICIENT_SPACE is coming from? I'm guessing both the S2/C4 are hitting this but not the S1 because the S1 has less configuration. This indeed used to work fine in the past.

[sjorge]

It seems to be coming up from the z-stack, do the newer firmware have reduced buffer sizing somewhere to make room for more routing table space?

[Danit2]

Thanks @sjorge for your analysis but I'm not sure if this is because of the firmware.
I'm not exactly sure, but I think I configured the last devices with this firmware and had no problems. But you're probably right.

Is it possible to downgrade the firmware or can this cause problems?

[sjorge]

You can downgrade the coordinator firmware, not sure where else this error could be coming from. I definitely already read and configured these devices on the current device side firmware.I might try an older coordinator firmware this weekend it i have some time. But also dont want to mess around too much since i finally have it stable without crashing all the time.~ sjorgeOn 2 Jan 2023, at 17:16, Danit2 @.***> wrote: Thanks @sjorge for your analysis but I'm not sure if this is because of the firmware. I'm not exactly sure, but I think I configured the last devices with this firmware and had no problems. But you're probably right. Is it possible to downgrade the firmware or can this cause problems?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[Danit2]

@sjorge I have test it now with a other stick with firmware version 20220219 and have the same error. and i am very shure with this version it was working. so i don't think it is the firmware.

[sjorge]

I also tested with 20220219 and still have the problem too on my S2/C4's.

@Koenkk any idea what could be triggering this INSUFFICIENT_SPACE ?

[Koenkk]

@sjorge this means the memory of the device is full (added to too many groups, bindings or configured reportings)

[sjorge]

That would be very odd as the config written to the device hasnt changed and is working fine still. It’s just no longer possible to read it ir write any new one.

[Koenkk]

@sjorge could it be that the fw has been updated recently? This could also be a bug in the device fw.

[sjorge]

Mine have been on the 2.x release for a while and i know i completely reconfigured one after.

I wonder if there is some sort of on device log space or something that filled up. Or maybe the routing table? My network has gotten a lot bigger recently.

@Danit2 how big is yours? Mine hovers around 90 devices, about 2/3 routers.

[Danit2]

The size of the network can't be the reason either. I have 49 devices and about 3/4 are routers. But I have a friend who only started with the smart home and only has 6 devices. He also gets the same error.

but maybe it's really the reporting or binding. because I have now tried again to read an s2 in which only the power metering is as reporting and no binding is configured. there it works.

what are we doing now?

@sjorge can you also try to delete the binding and delete the reporting? then try to read. maybe it works for you too? then it would really be a problem with ubisys and the firmware.

[sjorge]

Well i have mine bound to groups as i use them to control the lights in it, I had it like that since the beginning so removing all binds would kind of make them useless.

I’ll try and check tomorrow after work if some extra binds are there that are not suppose to be their.

[sjorge]

Very interesting my C4 shows bindings that are not connect, it has everything bound to the coordinator and nothing to the 2 groups i am controlling with them. I wonder how that happened.

I’ll see if i can remove them when i am at my laptop.

[Danit2]

I've played around a bit now. At the moment I can read everything on the J1 and S2. Also with all reporting and binding. But I can't read the D1 and C4. Even if no reporting or binding is programmed. I don't know where the problem is now. Maybe it really is a firmware bug

[sjorge]

Since all the binding on my C4 were not the ones it was suppose to be (all to coordinator, not to the group they are controlling). I nuked them and tried reading again:

debug 2023-01-05 10:24:05: Received MQTT message on 'zigbee2mqtt/switch/livingroom/light_bottom/get/configure_device_setup' with data ''
debug 2023-01-05 10:24:05: Publishing get 'get' 'configure_device_setup' to 'switch/livingroom/light_bottom'
debug 2023-01-05 10:24:06: Received Zigbee message from 'switch/livingroom/light_bottom', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputConfigurations":[0,0,0,0]}' from endpoint 232 with groupID 0
error 2023-01-05 10:24:06: Publish 'get' 'configure_device_setup' to 'switch/livingroom/light_bottom' failed: 'Error: Read 0x001fee0000005baa/232 manuSpecificUbisysDeviceSetup(["inputConfigurations","inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')'
info  2023-01-05 10:24:06: MQTT publish: topic 'zigbee2mqtt/switch/livingroom/light_bottom', payload '{"configure_device_setup":{"input_configurations":[0,0,0,0]},"linkquality":94,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}'

This is a super weird result as it did seem return some data but not all and not the data I was expecting. I wonder if we should split the inputConfigurations and inputActions reads?

[sjorge]

debug 2023-01-05 10:32:17: Publishing get 'get' 'configure_device_setup' to 'switch/livingroom/light_bottom'
debug 2023-01-05 10:32:17: Received Zigbee message from 'switch/livingroom/light_bottom', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputConfigurations":[0,0,0,0]}' from endpoint 232 with groupID 0
debug 2023-01-05 10:32:17: Received Zigbee message from 'switch/livingroom/light_bottom', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputActions":[{"data":[0,7,1,6,0,2],"type":"Buffer"},{"data":[0,134,1,8,0,1,0,50],"type":"Buffer"},{"data":[0,198,1,8,0,1,1,50],"type":"Buffer"},{"data":[0,11,1,8,0,3],"type":"Buffer"},{"data":[1,7,2,6,0,2],"type":"Buffer"},{"data":[1,134,2,8,0,1,0,50],"type":"Buffer"},{"data":[1,198,2,8,0,1,1,50],"type":"Buffer"},{"data":[1,11,2,8,0,3],"type":"Buffer"}]}' from endpoint 232 with groupID 0
info  2023-01-05 10:32:18: MQTT publish: topic 'zigbee2mqtt/switch/livingroom/light_bottom', payload '{"configure_device_setup":{"input_actions":[[0,7,1,6,0,2],[0,134,1,8,0,1,0,50],[0,198,1,8,0,1,1,50],[0,11,1,8,0,3],[1,7,2,6,0,2],[1,134,2,8,0,1,0,50],[1,198,2,8,0,1,1,50],[1,11,2,8,0,3]]},"linkquality":94,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}'```

[sjorge]

We're getting somewhere, but looks like it now only adds the last key. So there is now just question why my binds are missing... and how to fix this.

I'll try to find time this weekend to dig into this some more.

[sjorge]

I got a PR that mostly fix the INSUFFICIENT_SPACE. However if you have configure_device_setup disabled for caching (like I do) then it will only return configure_device_setup.input_actions if you have debounce also set.

@Koenkk It looks like debounce does not deepmerge keys that are objects/hashes, This is not what I expect to happen. Was this a deliberate choice? If not I'll see if I can fix this.

[sjorge]

Looks like the binds got reset (does not explain the group bind being missing though) when the configure functions got updates to add readMeteringMultiplierDivisor. So that at least partially explains it.

[Danit2]

I have now tested your new converter.
now it works again with my D1. not yet with the C4 because I still have the same error.

but if this only works again with a change to the converter, is it really a problem with the device or with the software?

Does it work for you with the C4 as well?

[sjorge]

I got it working on my C4 and all my S1's, one of my S2's is still not happy. I did already delete all my bindings to the coordinator on the C4, S1, and S2's and only kept the group bindings I was using.

I think it might be a bit of both, where some device side limit got smaller with the 1.x -> 2.x update but we are also doing a few things together that we don't need to. Now it's 2 reads vs 1 so more traffic on the mesh, but that is prefered over it not working.

I don't see how we can break this up further though 🤔

[Danit2]

Everything works for me except my two C4. They don't want to. :(

Theoretically, it's not that bad if it doesn't work. we don't really need this.

But I think we should definitely rewrite the converter so that it doesn't read the configuration when you write a new configuration. so there is no error.

when I write a new configuration, the program always crashes. this must not be.

can you do this? or can we catch the error that the programm not will crash?

[sjorge]

The set side is actually where I got the idea of splitting the read, as it writes each one separately already.

I'd much rather try and further figure out what is failing. Can you grab a debug log of the write to your C4 ?

[Danit2]

Zigbee2MQTT:debug 2023-01-05 20:05:13: Received MQTT message on 'zigbee2mqtt/Wohnzimmer_Taster/set' with data '{
    "configure_device_setup": {
        "input_action_templates": [
            {
                "type": "dimmer_double"
            },
            {
                "type": "dimmer_double"
            }
        ]
    }
}'
Zigbee2MQTT:debug 2023-01-05 20:05:13: Publishing 'set' 'configure_device_setup' to 'Wohnzimmer_Taster'
Zigbee2MQTT:warn  2023-01-05 20:05:13: ubisys: Using input(s) 0,1 and endpoint 1 for 'dimmer_double'.
Zigbee2MQTT:warn  2023-01-05 20:05:13: ubisys: Using input(s) 2,3 and endpoint 2 for 'dimmer_double'.
Zigbee2MQTT:debug 2023-01-05 20:05:13: ubisys: input_actions to be sent to 'undefined': [[0,7,1,6,0,1],[0,6,1,8,0,5,0,50],[0,11,1,8,0,3],[1,7,1,6,0,0],[1,6,1,8,0,5,1,50],[1,11,1,8,0,3],[2,7,2,6,0,1],[2,6,2,8,0,5,0,50],[2,11,2,8,0,3],[3,7,2,6,0,0],[3,6,2,8,0,5,1,50],[3,11,2,8,0,3]]
Zigbee2MQTT:info  2023-01-05 20:05:13: MQTT publish: topic 'zigbee2mqtt/Wohnzimmer_Taster', payload '{"action":null,"configure_device_setup":{"input_configurations":[0,0,0,0]},"last_seen":"2023-01-05T20:05:13+01:00","linkquality":91,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2023-01-05 20:05:13: Received Zigbee message from 'Wohnzimmer_Taster', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputConfigurations":[0,0,0,0]}' from endpoint 232 with groupID 0
Zigbee2MQTT:info  2023-01-05 20:05:14: MQTT publish: topic 'zigbee2mqtt/Wohnzimmer_Taster', payload '{"action":null,"configure_device_setup":{"input_configurations":[0,0,0,0]},"last_seen":"2023-01-05T20:05:13+01:00","linkquality":91,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2023-01-05 20:05:14: Received Zigbee message from 'Wohnzimmer_Taster', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{}' from endpoint 232 with groupID 0
Zigbee2MQTT:info  2023-01-05 20:05:14: MQTT publish: topic 'zigbee2mqtt/Wohnzimmer_Taster', payload '{"action":null,"configure_device_setup":{"input_configurations":[0,0,0,0]},"last_seen":"2023-01-05T20:05:14+01:00","linkquality":91,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'
Error: Read 0x001fee0000008d0d/232 manuSpecificUbisysDeviceSetup(["inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')
    at Endpoint.checkStatus (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:317:28)
    at Endpoint.read (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:480:22)
    at Object.convertGet (/app/data/extension/externally-loaded.js:516:17)

[Danit2]

This is the debug log and then the software crash.

[sjorge]

Very interesting, mostly this bit ubisys: input_actions to be sent to 'undefined':

I'll try to see if I can see why this is happening tomorrow.

[sjorge]

Ok I fixed the undefined, but that was a red herring.

@Koenkk I'm super confused by this though, it looks like the write succeeds fine, but when we read the result after we hit INSUFFICIENT_SPACE AND we somehow crash z2m.

The write working but the read failing makes no sense, I will try to get a packet capture this weekend of me doing the write and then the read after (well that will happen automatically). Hopefully that will hold some clues.

Both failing or both succeeding would make sense but not the write working and the read failing. In both cases we only do them one attribute at a time.

[sjorge]

@Danit2 can you try the change I have in the PR again? The undefined should now be gone, and the crash too. We still get INSUFFICIENT_SPACE unfortunately.

[Danit2]

Zigbee2MQTT:debug 2023-01-05 21:53:04: Received MQTT message on 'zigbee2mqtt/Wohnzimmer_Taster/set' with data '{
    "configure_device_setup": {
        "input_action_templates": [
            {
                "type": "dimmer_double"
            },
            {
                "type": "dimmer_double"
            }
        ]
    }
}'
Zigbee2MQTT:debug 2023-01-05 21:53:04: Publishing 'set' 'configure_device_setup' to 'Wohnzimmer_Taster'
Zigbee2MQTT:warn  2023-01-05 21:53:04: ubisys: Using input(s) 0,1 and endpoint 1 for 'dimmer_double'.
Zigbee2MQTT:warn  2023-01-05 21:53:04: ubisys: Using input(s) 2,3 and endpoint 2 for 'dimmer_double'.
Zigbee2MQTT:debug 2023-01-05 21:53:04: ubisys: input_actions to be sent to 'Wohnzimmer_Taster': [[0,7,1,6,0,1],[0,6,1,8,0,5,0,50],[0,11,1,8,0,3],[1,7,1,6,0,0],[1,6,1,8,0,5,1,50],[1,11,1,8,0,3],[2,7,2,6,0,1],[2,6,2,8,0,5,0,50],[2,11,2,8,0,3],[3,7,2,6,0,0],[3,6,2,8,0,5,1,50],[3,11,2,8,0,3]]
Zigbee2MQTT:info  2023-01-05 21:53:04: MQTT publish: topic 'zigbee2mqtt/Wohnzimmer_Taster', payload '{"action":null,"configure_device_setup":{"input_configurations":[0,0,0,0]},"last_seen":"2023-01-05T21:53:04+01:00","linkquality":91,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2023-01-05 21:53:04: Received Zigbee message from 'Wohnzimmer_Taster', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputConfigurations":[0,0,0,0]}' from endpoint 232 with groupID 0
Zigbee2MQTT:info  2023-01-05 21:53:04: MQTT publish: topic 'zigbee2mqtt/Wohnzimmer_Taster', payload '{"action":null,"configure_device_setup":{"input_configurations":[0,0,0,0]},"last_seen":"2023-01-05T21:53:04+01:00","linkquality":91,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2023-01-05 21:53:04: Received Zigbee message from 'Wohnzimmer_Taster', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{}' from endpoint 232 with groupID 0
Zigbee2MQTT:info  2023-01-05 21:53:04: MQTT publish: topic 'zigbee2mqtt/Wohnzimmer_Taster', payload '{"action":null,"configure_device_setup":{"input_configurations":[0,0,0,0]},"last_seen":"2023-01-05T21:53:04+01:00","linkquality":91,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'
Zigbee2MQTT:error 2023-01-05 21:53:04: Publish 'set' 'configure_device_setup' to 'Wohnzimmer_Taster' failed: 'Error: Read 0x001fee0000008d0d/232 manuSpecificUbisysDeviceSetup(["inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')'
Zigbee2MQTT:debug 2023-01-05 21:53:04: Error: Read 0x001fee0000008d0d/232 manuSpecificUbisysDeviceSetup(["inputActions"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INSUFFICIENT_SPACE')
    at Endpoint.checkStatus (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:317:28)
    at Endpoint.read (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:480:22)
    at Object.convertGet (/app/data/extension/externally-loaded.js:523:17)
    at Object.convertSet (/app/data/extension/externally-loaded.js:516:17)
    at Publish.onMQTTMessage (/app/lib/extension/publish.ts:246:36)
Zigbee2MQTT:info  2023-01-05 21:53:04: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'configure_device_setup' to 'Wohnzimmer_Taster' failed: 'Error: Read 0x001fee0000008d0d/232 manuSpecificUbisysDeviceSetup([\"inputActions\"], {\"sendWhen\":\"immediate\",\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":true,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Status 'INSUFFICIENT_SPACE')'","meta":{"friendly_name":"Wohnzimmer_Taster"},"type":"zigbee_publish_error"}'

[Danit2]

This is the new debug log. Now it goes without a crash. Thanks for that.

[sjorge]

OK, so the things I expected to be fixed seem to indeed be fixed.

Is the config you wrote to the device working properly?

[Danit2]

Yes there work without no problem. To set a new configuration is not the problem. Only to read back.

Here is a debug log when i change the input on a S2. There it works without problem.

Zigbee2MQTT:debug 2023-01-05 22:30:37: Received MQTT message on 'zigbee2mqtt/Esszimmer_Steckdose/set' with data '{
    "configure_device_setup": {
        "input_action_templates": [
            {
                "type": "dimmer_double"
            }
        ]
    }
}'
Zigbee2MQTT:debug 2023-01-05 22:30:37: Publishing 'set' 'configure_device_setup' to 'Esszimmer_Steckdose'
Zigbee2MQTT:warn  2023-01-05 22:30:37: ubisys: Using input(s) 0,1 and endpoint 3 for 'dimmer_double'.
Zigbee2MQTT:debug 2023-01-05 22:30:37: ubisys: input_actions to be sent to 'Esszimmer_Steckdose': [[0,7,3,6,0,1],[0,6,3,8,0,5,0,50],[0,11,3,8,0,3],[1,7,3,6,0,0],[1,6,3,8,0,5,1,50],[1,11,3,8,0,3]]
Zigbee2MQTT:info  2023-01-05 22:30:37: MQTT publish: topic 'zigbee2mqtt/Esszimmer_Steckdose', payload '{"action":null,"configure_device_setup":{"input_actions":[[0,13,3,6,0,2],[1,13,4,6,0,2]],"input_configurations":[0,0]},"energy":1.47,"last_seen":"2023-01-05T22:30:37+01:00","linkquality":0,"power":0,"power_on_behavior_l1":"previous","power_on_behavior_l2":"previous","state_l1":"OFF","state_l2":"OFF","update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2023-01-05 22:30:37: Received Zigbee message from 'Esszimmer_Steckdose', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputConfigurations":[0,0]}' from endpoint 232 with groupID 0
Zigbee2MQTT:info  2023-01-05 22:30:37: MQTT publish: topic 'zigbee2mqtt/Esszimmer_Steckdose', payload '{"action":null,"configure_device_setup":{"input_actions":[[0,13,3,6,0,2],[1,13,4,6,0,2]],"input_configurations":[0,0]},"energy":1.47,"last_seen":"2023-01-05T22:30:37+01:00","linkquality":0,"power":0,"power_on_behavior_l1":"previous","power_on_behavior_l2":"previous","state_l1":"OFF","state_l2":"OFF","update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2023-01-05 22:30:37: Received Zigbee message from 'Esszimmer_Steckdose', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{"inputActions":[{"data":[0,7,3,6,0,1],"type":"Buffer"},{"data":[0,6,3,8,0,5,0,50],"type":"Buffer"},{"data":[0,11,3,8,0,3],"type":"Buffer"},{"data":[1,7,3,6,0,0],"type":"Buffer"},{"data":[1,6,3,8,0,5,1,50],"type":"Buffer"},{"data":[1,11,3,8,0,3],"type":"Buffer"}]}' from endpoint 232 with groupID 0
Zigbee2MQTT:info  2023-01-05 22:30:37: MQTT publish: topic 'zigbee2mqtt/Esszimmer_Steckdose', payload '{"action":null,"configure_device_setup":{"input_actions":[[0,7,3,6,0,1],[0,6,3,8,0,5,0,50],[0,11,3,8,0,3],[1,7,3,6,0,0],[1,6,3,8,0,5,1,50],[1,11,3,8,0,3]],"input_configurations":[0,0]},"energy":1.47,"last_seen":"2023-01-05T22:30:37+01:00","linkquality":0,"power":0,"power_on_behavior_l1":"previous","power_on_behavior_l2":"previous","state_l1":"OFF","state_l2":"OFF","update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"},"update_available":false}'

On this log i change the action from two times toggle to dimmer_double

[sjorge]

Looks like this landed in the hotfix release 🥳

Still going to do the package capture this weekend (if I can), I want to know why we can write the big payloads and they work. But not read them again. That makes no sense.

[ahemwe]

Does this issue and the fix also cover #15171? There, the same error message is mentioned in a log, while it focusses more on implausible action states. (e.g. toggle instead of _toggle1)

[sjorge]

Does this issue and the fix also cover #15171? There, the same error message is mentioned in a log, while it focusses more on implausible action states. (e.g. toggle instead of _toggle1)

It will no longer crash when trying to read the configuration (which is also done after a write) when we hit INSUFFICIENT_SPACE. But we still can't read the value in a lot of cases and still get this error.

It changes nothing with regard to the action values though so I doubt those will change.

[sjorge]

@ahemwe at least for me this is working fine though?

{"action":"toggle","action_group":10503,"linkquality":36,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}
{"action":"toggle","action_group":10102,"linkquality":61,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}

I only have 2 buttons configure and they both report the toggle action for the proper action_group that they are assigned to.

[ahemwe]

Do you refer to latest commit on master or dev? @sjorge
I'm running on master (1.29.1) and found this:

Sending a default configuration as listed in documentation at mqtt topic zigbee2mqtt/Esszimmer/Wand/Schalter/set:

{
    "configure_device_setup": {
        "input_action_templates": [
            {             
                "type": "toggle"
            },
            {             
                "type": "toggle"
            }
        ]
    }
}

Results in that log:

Jan 06 12:53:04 raspberrypi npm[22987]: Zigbee2MQTT:warn  2023-01-06 12:53:04: ubisys: Using input(s) 0 and endpoint 1 for 'toggle'.
Jan 06 12:53:04 raspberrypi npm[22987]: Zigbee2MQTT:warn  2023-01-06 12:53:04: ubisys: Using input(s) 1 and endpoint 2 for 'toggle'.
Jan 06 12:53:04 raspberrypi npm[22987]: Zigbee2MQTT:info  2023-01-06 12:53:04: MQTT publish: topic 'zigbee2mqtt/Esszimmer/Wand/Schalter', payload '{"configure_device_setup":{"input_actions":[[0,13,1,6,0,2]],"input_configurations":[0,0,0,0]},"last_seen":"2023-01-06T12:53:04+01:00","linkquality":255,"update":{"installed_version":17039684,"latest_version":26345997,"state":"available"},"update_available":true}'
Jan 06 12:53:04 raspberrypi npm[22987]: Zigbee2MQTT:info  2023-01-06 12:53:04: MQTT publish: topic 'zigbee2mqtt/Esszimmer/Wand/Schalter', payload '{"configure_device_setup":{"input_actions":[[0,13,1,6,0,2]],"input_configurations":[0,0,0,0]},"elapsed":23701,"last_seen":"2023-01-06T12:53:04+01:00","linkquality":255,"update":{"installed_version":17039684,"latest_version":26345997,"state":"available"},"update_available":true}'
Jan 06 12:53:04 raspberrypi npm[22987]: Zigbee2MQTT:info  2023-01-06 12:53:04: MQTT publish: topic 'zigbee2mqtt/Esszimmer/Wand/Schalter', payload '{"configure_device_setup":{"input_actions":[[0,13,1,6,0,2],[1,13,2,6,0,2]],"input_configurations":[0,0,0,0]},"elapsed":68,"last_seen":"2023-01-06T12:53:04+01:00","linkquality":255,"update":{"installed_version":17039684,"latest_version":26345997,"state":"available"},"update_available":true}'

If I then press a button I see this message on zigbee, which has no information about the actual channel. (device is not bound to any other device apart from coordinator):

{
  "action" : "toggle",
  "configure_device_setup" : {
    "input_actions" : [ [ 0, 13, 1, 6, 0, 2 ], [ 1, 13, 2, 6, 0, 2 ] ],
    "input_configurations" : [ 0, 0, 0, 0 ]
  },
  "elapsed" : 2996,
  "last_seen" : "2023-01-06T12:56:38+01:00",
  "linkquality" : 255,
  "update" : {
    "installed_version" : 17039684,
    "latest_version" : 26345997,
    "state" : "available"
  },
  "update_available" : true
}

[sjorge]

You probably do need to bind it to a group for the action_group to show up, I’ll have a look this weekend we can fallback to append endpoint name like other devices do if there is no group.

[sjorge]

@ahemwe could you turn on debug logging and toggle your buttons again? That should include all the info about groups and stuff, if I'm correct that should be 0 in your case.

[Danit2]

I only have 2 buttons configure and they both report the toggle action for the proper action_group that they are assigned to.

But @sjorge this is wrong. When you have 2 buttons configured then they must report 1_toggle and 2_toggle But woud it be not better to make the actions simular to all the other actions in Z2M?

So why is in the C4 converter the fz.legacy.ubisys_c4_onoff and not the normal converter? Is it not easy to use the normal converter and use the normal meta: {multiEndpoint: true}

By the way: the toggle converter missing.

Maby i will rewreit the c4 converter that it will be consistent to the rest of Z2M.

So then we will have toggle_1

What do you think?

[sjorge]

Yeah I was going to see if switching to the normal one works or not.

I think dropping the legacy one and adding: fz.on_off, fz.command_toggle, fz.command_on, fz.command_off, fz.command_recall, fz.command_move,fz.command_stop might work.

[Danit2]

    {
        zigbeeModel: ['C4 (5504)'],
        model: 'C4',
        vendor: 'Ubisys',
        description: 'Control unit C4',
        fromZigbee: [fz.command_toggle, fz.command_on, fz.command_off, fz.command_recall,
            fz.command_move, fz.command_stop, fz.command_cover_stop, fz.command_cover_open,
            fz.command_cover_close, ubisys.fz.configure_device_setup],
        toZigbee: [ubisys.tz.configure_device_setup],
        exposes: [e.action([
            'scene_*_1', 'on_1', 'off_1', 'toggle_1', 'level_move_down_1', 'level_move_up_1',
            'scene_*_2', 'on_2', 'off_2', 'toggle_2', 'level_move_down_2', 'level_move_up_2',
            'scene_*_3', 'on_3', 'off_3', 'toggle_3', 'level_move_down_3', 'level_move_up_3',
            'scene_*_4', 'on_4', 'off_4', 'toggle_4', 'level_move_down_4', 'level_move_up_4',
            'scene_*_5', 'cover_open_5', 'cover_close_5', 'cover_stop_5',
            'scene_*_6', 'cover_open_6', 'cover_close_6', 'cover_stop_6'])],
        configure: async (device, coordinatorEndpoint, logger) => {
            for (const ep of [1, 2, 3, 4]) {
                await reporting.bind(device.getEndpoint(ep), coordinatorEndpoint, ['genScenes', 'genOnOff', 'genLevelCtrl']);
            }
            for (const ep of [5, 6]) {
                await reporting.bind(device.getEndpoint(ep), coordinatorEndpoint, ['genScenes', 'closuresWindowCovering']);
            }
        },
        meta: {multiEndpoint: true},
        endpoint: (device) => {
            return {'1': 1, '2': 2, '3': 3, '4': 4, '5': 5, '6': 6};
        },
        ota: ota.ubisys,
    },

[Danit2]

I think somethin likt this must work.

[sjorge]

    ubisys_c4_onoff: {
        cluster: 'genOnOff',
        type: ['commandOn', 'commandOff', 'commandToggle'],
        options: [exposes.options.legacy()],
        convert: (model, msg, publish, options, meta) => {
            if (!isLegacyEnabled(options)) {
                if (msg.type === 'commandOn') {
                    return fromZigbeeConverters.command_on.convert(model, msg, publish, options, meta);
                } else if (msg.type === 'commandOff') {
                    return fromZigbeeConverters.command_off.convert(model, msg, publish, options, meta);
                } else if (msg.type === 'commandToggle') {
                    return fromZigbeeConverters.command_toggle.convert(model, msg, publish, options, meta);
                }
            }
            return {action: `${msg.endpoint.ID}_${msg.type.substr(7).toLowerCase()}`};
        },
    },

So looks like if legacy is set to false in z2m, which it is for me, it passes them through to the non legacy converters already. So the event should be the same if we just set multiEndpoint

[sjorge]

We should probably set the endpoint array to so it's inline with the other Ubisys devices:

        endpoint: (device) => {
            return {'s1': 1, 's2': 2, 's3': 3, 's4': 4};
        },

S1 and S2 have s1 and s1/s2 respectively for the endpoints matching the markings on the device.

[sjorge]

Indeed it just works with setting endpoint and multiendpoint, I'll make a PR

{"action":"toggle_s1","action_group":10503,"linkquality":61,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}
{"action":"toggle_s1","action_group":10503,"linkquality":76,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}
{"action":"toggle_s2","action_group":10102,"linkquality":83,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}
{"action":"toggle_s2","action_group":10102,"linkquality":58,"update":{"installed_version":33555200,"latest_version":33555200,"state":"idle"}}

[Danit2]

cool ok yes we can do also s as endpoint name. But dose someone need the legacy converter?

[sjorge]

But dose someone need the legacy converter?

idk, but generally Koen tries not to break things hence we have the whole set of fz.legacy. to begin with.

cool ok yes we can do also s as endpoint name. Wrapping up a PR now...

[Danit2]

When you let the legacy converter then you have also the problem that the converter return a 1_on but in Z2M it is standart to repot as on_s1 i never see a converter that report firt the number and then the state.

[ahemwe]

@ahemwe could you turn on debug logging and toggle your buttons again? That should include all the info about groups and stuff, if I'm correct that should be 0 in your case.

That's the log when enabling debugging @sjorge

Jan 06 13:43:59 raspberrypi npm[22987]: Zigbee2MQTT:debug 2023-01-06 13:43:59: Received Zigbee message from 'Esszimmer/Wand/Schalter', type 'commandToggle', cluster 'genOnOff', data '{}' from endpoint 2 with groupID null
Jan 06 13:43:59 raspberrypi npm[22987]: Zigbee2MQTT:info  2023-01-06 13:43:59: MQTT publish: topic 'zigbee2mqtt/Esszimmer/Wand/Schalter', payload '{"action":"toggle","configure_device_setup":{"input_actions":[[0,13,1,6,0,2],[1,13,2,6,0,2]],"input_configurations":[0,0,0,0]},"elapsed":12639,"last_seen":"2023-01-06T13:43:59+01:00","linkquality":255,"update":{"installed_version":17039684,"latest_version":26345997,"state":"available"},"update_available":true}'
Jan 06 13:44:07 raspberrypi npm[22987]: Zigbee2MQTT:debug 2023-01-06 13:44:07: Received Zigbee message from 'Esszimmer/Wand/Schalter', type 'commandToggle', cluster 'genOnOff', data '{}' from endpoint 1 with groupID null
Jan 06 13:44:07 raspberrypi npm[22987]: Zigbee2MQTT:info  2023-01-06 13:44:07: MQTT publish: topic 'zigbee2mqtt/Esszimmer/Wand/Schalter', payload '{"action":"toggle","configure_device_setup":{"input_actions":[[0,13,1,6,0,2],[1,13,2,6,0,2]],"input_configurations":[0,0,0,0]},"elapsed":8389,"last_seen":"2023-01-06T13:44:07+01:00","linkquality":255,"update":{"installed_version":17039684,"latest_version":26345997,"state":"available"},"update_available":true}'