After configuration of a Ubisys Device i get a (Status 'INSUFFICIENT_SPACE')
#15875
Comments
Reading from an S1Reading from an S2Reading from an C4@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. |
|
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? |
|
Thanks @sjorge for your analysis but I'm not sure if this is because of the firmware. Is it possible to downgrade the firmware or can this cause problems? |
|
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: ***@***.***>
|
|
@sjorge I have test it now with a other stick with firmware version |
|
I also tested with @Koenkk any idea what could be triggering this |
|
@sjorge this means the memory of the device is full (added to too many groups, bindings or configured reportings) |
|
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. |
|
@sjorge could it be that the fw has been updated recently? This could also be a bug in the device fw. |
|
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. |
|
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. |
|
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. |
|
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. |
|
I've played around a bit now. |
|
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: This is a super weird result as it did seem return some data but not all and not the data I was expecting. |
|
|
We're getting somewhere, but looks like it now only adds the last key. I'll try to find time this weekend to dig into this some more. |
|
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. |
|
Looks like the binds got reset (does not explain the group bind being missing though) when the configure functions got updates to add |
|
I have now tested your new converter. 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? |
|
I got it working on my C4 and all my S1's, one of my S2's is still not happy. 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 🤔 |
|
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? |
|
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 ? |
|
|
This is the debug log and then the software crash. |
|
Very interesting, mostly this bit I'll try to see if I can see why this is happening tomorrow. |
|
Do you refer to latest commit on master or dev? @sjorge Sending a default configuration as listed in documentation at mqtt topic zigbee2mqtt/Esszimmer/Wand/Schalter/set: Results in that log: 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): |
|
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. |
|
@ahemwe could you turn on debug logging and toggle your buttons again? |
But @sjorge this is wrong. When you have 2 buttons configured then they must report So why is in the C4 converter the By the way: the Maby i will rewreit the c4 converter that it will be consistent to the rest of Z2M. So then we will have What do you think? |
|
Yeah I was going to see if switching to the normal one works or not. I think dropping the legacy one and adding: |
|
|
I think somethin likt this must work. |
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 |
|
We should probably set the endpoint array to so it's inline with the other Ubisys devices: S1 and S2 have s1 and s1/s2 respectively for the endpoints matching the markings on the device. |
|
Indeed it just works with setting endpoint and multiendpoint, I'll make a PR |
|
cool ok yes we can do also |
idk, but generally Koen tries not to break things hence we have the whole set of fz.legacy. to begin with.
|
|
When you let the legacy converter then you have also the problem that the converter return a |
That's the log when enabling debugging @sjorge |
I've swapped the expose values to be the non legacy one. I'll ask koen if he's OK with just eliminating it and using fz.command_* instead. |
|
@Koenkk the You can use this filter I think you still have my nwk key, if not I can pass it again on discord. But I also copied the values here for the effected packets, which is probably even easier. The write: The read: |
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days |
|
There is now a 2.2.1 firmware for most devices: Not sure the issue will be solved, but they at least seem to have made a bunch of changes so perhaps the firmware now accepts larger payloads again. |
|
Does updating require a special hardware or can this be done out of zigbee2mqtt? |
|
Well, it use to just work using zigbee2mqtt but it looks like it got broken a while ago :( Koenkk/zigbee-OTA#329 Someone added a bunch of older firmware to the zigbee-OTA repo and swapped the providers, only the two they forgot to swap it for now show the new update. |
|
I have a potential fix for this, anyone available that can test this? If you are running the februari release you can replace Edit: I might have destroyed my C4 and my testing S1 with this. Please don't test with the code I posted earlier. |
|
Got a fixed version up now, only tested against my S1 and S2 but seems fine. Due to a coding error I was writing random data before which bricked one of my devices. |
|
This is now fixed in the latest dev release, should be in the april stable release. |
|
@sjorge cool thanks a lot. |
What happened?
When i want to configure the
input_actionof 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_actionwill work but only the read back make the problem.When i only read back the configuration with:
zigbee2mqtt/FRIENDLY_NAME/get/configure_device_setupi get this error:When i want to set a new configuration i get the same error but z2m will crash with this error:
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_actionof 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
The text was updated successfully, but these errors were encountered: