Reporting tab interface completely broken after 1.33.1 update #19317
Comments
|
I connected my new sensor E2112 yesterday - and there is no data from it except LQI. Zigbee2MQTT version |
|
Hi,
|
|
@alexh3o could you provide your data/database.db? |
|
Here is the part for ZLinky
I can send the whole database.db if it's useful, should I do it here or through a more private channel ? |
|
I'm also affected by this. In my case, duplication occurs when I'm updating values in the Reporting tab. |
|
Same issue with freshly released After updating
After a page reload, value is back and new row is still here:
I can remove the new line. On another device, the same behavior was fixed by repairing (removing/pairing). |
|
Hi, if you remove and repair your device, you can configure reporting without having duplicates after ? |
|
Just updated to 1.34.0 and now (without doing anything) many "entities" in database.db are duplicated and reported with default/wrong Reporting times/repo_changes together with the new "manufacturerCode: null" JSON attribute..... Those duplicated entities are the same that was previously affected by this duplication bug when we was trying to update their values. A questions: should we keep the ones with "manufacturerCode: null" (because it's the new/right standard ATM) or the old ones without this new attribute? |
|
Pushed a fix! After upgrading, click Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html) |
Unfortunately switching to Dev branch doesn't solve anything. Now Z2M neither starts.....
|
|
Can you try to execute |
|
Different error but unable to run Z2M.
|
|
What if you execute |
Using latest DEV there isn't any issue during start. Just a small "glitch": just after click "Apply" the duplicated entry still remains there, but a page refresh fixes this. |
I appear to be running the "fixed" version, but pressing "Apply" does not fix the issue for me (even after a page refresh) Also tried on a device without duplicates... I now have duplicates :-( |
|
Same here. I tried few days ago and duplication is still here. |
Could you provide the data/database.db entry of this device? |
|
I'm not sure which version broke this for me, it's been happening for a few months at least.
It also happens for SPLZB-134 smart plugs.
Looking at the data from the database I see that the duplicated entries all have "manufacturerCode": null
Thanks
/nick
{
"id": 18,
"type": "EndDevice",
"ieeeAddr": "0x00178801032ab969",
"nwkAddr": 11099,
"manufId": 4107,
"manufName": "Philips",
"powerSource": "Battery",
"modelId": "SML001",
"epList": [
1,
2
],
"endpoints": {
"1": {
"profId": 49246,
"epId": 1,
"devId": 2128,
"inClusterList": [
0
],
"outClusterList": [
0,
3,
4,
6,
8,
768,
5
],
"clusters": {},
"binds": [],
"configuredReportings": [],
"meta": {}
},
"2": {
"profId": 260,
"epId": 2,
"devId": 263,
"inClusterList": [
0,
1,
3,
1030,
1024,
1026
],
"outClusterList": [
25
],
"clusters": {
"genPowerCfg": {
"attributes": {
"batteryPercentageRemaining": 45
}
},
"msTemperatureMeasurement": {
"attributes": {
"measuredValue": 1745
}
},
"msIlluminanceMeasurement": {
"attributes": {
"measuredValue": 15635
}
},
"msOccupancySensing": {
"attributes": {
"48": 2,
"occupancy": 0,
"pirOToUDelay": 0
}
}
},
"binds": [
{
"cluster": 1,
"type": "endpoint",
"deviceIeeeAddress": "0x00124b00238da250",
"endpointID": 1
},
{
"cluster": 1024,
"type": "endpoint",
"deviceIeeeAddress": "0x00124b00238da250",
"endpointID": 1
},
{
"cluster": 1026,
"type": "endpoint",
"deviceIeeeAddress": "0x00124b00238da250",
"endpointID": 1
},
{
"cluster": 1030,
"type": "endpoint",
"deviceIeeeAddress": "0x00124b00238da250",
"endpointID": 1
}
],
"configuredReportings": [
{
"cluster": 1,
"attrId": 33,
"minRepIntval": 900,
"maxRepIntval": 3600,
"repChange": 1
},
{
"cluster": 1030,
"attrId": 0,
"minRepIntval": 0,
"maxRepIntval": 3600,
"repChange": 0
},
{
"cluster": 1026,
"attrId": 0,
"minRepIntval": 300,
"maxRepIntval": 3600,
"repChange": 10
},
{
"cluster": 1024,
"attrId": 0,
"minRepIntval": 60,
"maxRepIntval": 3600,
"repChange": 200
},
{
"cluster": 1,
"attrId": 33,
"minRepIntval": 900,
"maxRepIntval": 3600,
"repChange": 1,
"manufacturerCode": null
}
],
"meta": {}
}
},
"appVersion": 2,
"stackVersion": 1,
"hwVersion": 1,
"dateCode": "20190219",
"swBuildId": "6.1.1.27575",
"zclVersion": 1,
"interviewCompleted": true,
"meta": {
"configured": 2
},
"lastSeen": 1703149418656,
"defaultSendRequestWhen": "immediate"
}
… On 21 Dec 2023, at 06:47, Koen Kanters ***@***.***> wrote:
@nplawes <https://github.com/nplawes>
Also tried on a device without duplicates... I now have duplicates :-(
Could you provide the data/database.db entry of this device?
—
Reply to this email directly, view it on GitHub <#19317 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHWUMJL2A2YPDK6XGUQBH3YKPLO5AVCNFSM6AAAAAA6DD4C22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRVGY2DQMRQGE>.
You are receiving this because you were mentioned.
|
Are you sure you're running 1.34-dev version? |
|
I don't see a docker tag for 1.34-dev. There is a latest-dev, which hopefully is stable enough to not break my live environment :-)
And indeed that does seem to fix matters, with 'apply' and refresh page.
Also fixes the annoying persistent pop-ups, which I was going to report on next :-)
Thanks
/nick
… On 21 Dec 2023, at 15:05, emandt ***@***.***> wrote:
I'm not sure which version broke
Are you sure you're running 1.34-dev version?
My duplicated values were fixed just by pressing "Apply" on those values, and then refresh the web page.
—
Reply to this email directly, view it on GitHub <#19317 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHWUMIFJDPFUHGFT7BZOM3YKRF4VAVCNFSM6AAAAAA6DD4C22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRWGQ2DEMBZG4>.
You are receiving this because you were mentioned.
|
Don't try on a production environment. Dev branch could be often broken and doesn't allow to start. |
|
Too late :-)
I do generally avoid using dev branches, and will switch back to the stable branch when it's next updated.
Although, I can obviously switch back to 'latest' now, if there is no incompatibility introduced by 'latest-dev'.
Fortunately I do have daily backups, so can revert in an emergency.
/nick
… On 21 Dec 2023, at 15:37, emandt ***@***.***> wrote:
I don't see a docker tag for 1.34-dev. There is a latest-dev, which hopefully is stable enough to not break my live environment
Don't try on a production environment. Dev branch could be often broken and doesn't allow to start.
—
Reply to this email directly, view it on GitHub <#19317 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHWUMKJFRZFACEVXQ25SHDYKRJVBAVCNFSM6AAAAAA6DD4C22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRWGUYDSNJXGM>.
You are receiving this because you were mentioned.
|
|
Ah I forgot this fix did not made it into 1.34.0, fix will be included in the 1 January release. |
|
That sounds great... The dev release seems fine at the moment, so I will switch back to the mainstream release next year.
Thanks!
/nick
… On 22 Dec 2023, at 07:50, Koen Kanters ***@***.***> wrote:
Ah I forgot this fix did not made it into 1.34.0, fix will be included in the 1 January release.
—
Reply to this email directly, view it on GitHub <#19317 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHWUMML3RBF2EYYRUL7LGDYKU3TXAVCNFSM6AAAAAA6DD4C22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGM2TEMZTGM>.
You are receiving this because you were mentioned.
|
What happened?
After upgrading to 1.33.1, my VINDSTYRKA devices were no longer updating at the rate that I had previously configured them. Upon going to the reporting tab, I noticed that all the clusters were listed twice, once with my original settings, and once with what appears to be the default. It also appears to be impossible to fix. I can disable all the extra entries except for pm25measurement, where I first have to change the attribute to measuredValueIkea, otherwise I get a
Request 'zigbee2mqtt/bridge/request/device/configure_reporting' failed with error: 'ConfigureReporting 0x385cfbfffea36292/1 pm25Measurement([{"attribute":"measuredValue","minimumReportInterval":60,"maximumReportInterval":65535,"reportableChange":2}], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'INVALID_DATA_TYPE')'However, attempting to change any of the settings results in more duplicates returning, though they seem to match my settings.
Screenshot of what this looks like after any attempt at editing:
What did you expect to happen?
A) zigbee2mqtt does not erase my previous reporting settings
B) I can actually use the reporting tab to adjust the settings.
How to reproduce it (minimal and precise)
Unsure what the minimum requirement is. As mentioned above, I'm using VINDSTYRKA devices (don't know if it's specific to them), and simply trying to set reporting settings.
Zigbee2MQTT version
1.33.1
Adapter firmware version
0x26580700
Adapter
ConBee2/RaspBee2
Debug log
log.txt
The text was updated successfully, but these errors were encountered: