Open Phil-ibert opened 1 year ago
This morning, I found Z2M in a "Not connected to MQTT" error loop again, without touching anything. On the MQTT Broker side, there was a packet malformed error each time Z2M tries to connect Removing the Zlinky solved this issue again.
Same thing happens with Z2M Edge.
@Koenkk How can I provide data to help solve this issue ?
How come the Zlinky can cause such issue ?
I am willing to solve this but I don't even know where to look...
Hi, I migrated today from 1.32 to 1.33 and had this problem of malformed packet for the Zlinky. I've just solved the problem by deleting some TICs (I was exposing everything because my Zen Flex tarif aka Pointe Mobile didn't exist yet). I'm not sure because I haven't tested everything, but I'd think it's due to the TICs NJOURF+1 and PJOURF+1.
Same issue here, enabling just some TICs and restarting Z2M did the trick
NJOURF+1 seems to be the one causing the issue I was able to enable PJOURF+1 without issues
Hi!
I am interested by this TIC enable feature that you are mentioning, as I am not familiar with it. Would you have a guide on how to enable/disable it ?
Also, how could we fix the issue with NJOURF+1 ? Thank you for your replies
It's in the device settings in Z2M user interface:
You have to list all values you need. You can find the list of all possible values in the ZLinky documentation: https://github.com/fairecasoimeme/Zlinky_TIC#mode-standard
Thank you very much for those information, I was able to confirm the issue with NJOURF+1 as you said. Hi @Koenkk, can you please point us towards what could cause this issue ?
Thank you !
Same issue for me and like you, when I filter NJOURF+1, it is working again. I looked at the code and I do not understand why there an issue with this. The value is a numeric ("days_number_next_calendar":0) so I do not know why it is being send as a malformed packet 😢
What's weird is for just a decimal value to crash the whole MQTT connection. How can we instrument this ?
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
Anybody has knowledge or ways to instrument this ?
Hello, I have the same problem with version 1.33.2. You don't need the Nour+1. In the Log Debug, no information, we just have everything ZigBee2mqtt that plants and restarts. I want to test a beta version.
Hello, same issue for me since my supplier tarif has been modified. I was previously in BASE tarif and I'm now in "H SUPER CREUSES" supplier pricing name (from Total Energies) which has 3 differents scheduled tarifs (Heures Pleines, Heures Creuses, Heures Super Creuses).
Was working perfectly before but not I have to remove it from Z2M in order to Z2M to work. Now, everytimes I add Zlinky to the zigbee network, I got error message : "Not connected to MQTT server!" and other devices are all in error too : "Cannot send message: topic: 'zigbee2mqtt/Machine à laver',..."
I confirm that removing "NJOURF+1" from the Tic command whitelist then restart Z2M seems to solve the issue.
Zigbee2MQTT version: 1.33.2 Coordinator type: EZSP v8 Coordinator revision: 6.10.3.0 build 297 Interface version: 0.6.142 Zigbee-herdsman-converters version: 15.106.0 Zigbee-herdsman version: 0.21.0
LiXee Zlinky_TIC firmware: 4000-0013
ZLinky_TIC Z2M state after removing "NJOURF+1" Tic command:
{ "MOTDETAT": null, "active_enerfy_out_d04": 5457.24, "active_register_tier_delivered": null, "apparent_power": 549, "available_power": 6, "current_tarif": "H SUPER CREUSES", "current_tier1_summ_delivered": null, "current_tier2_summ_delivered": null, "current_tier3_summ_delivered": null, "current_tier4_summ_delivered": null, "current_tier5_summ_delivered": null, "current_tier6_summ_delivered": null, "last_seen": "2023-11-21T17:48:29.490Z", "linkquality": 52, "meter_serial_number": "XXXXXXXXXXXX", "rms_current": 2, "rms_current_max": null, "rms_voltage": 239, "schedule_h_p_h_c": null, "tomorrow_color": null, "update": { "installed_version": 1, "latest_version": 13, "state": "available" }, "update_available": null, "warn_d_p_s": null, "active_enerfy_out_d01": 12514.453, "active_enerfy_out_d02": 7164.338, "active_enerfy_out_d03": 1623.872, "active_power": 404, "active_power_max": 8972, "active_power_ph_b": 752, "average_rms_voltage_meas_period": 237, "current_date": "H231121184818", "current_index_tarif": 3, "current_price": "HEURES PLEINES", "current_summ_delivered": null, "current_tier10_summ_delivered": null, "current_tier7_summ_delivered": null, "current_tier8_summ_delivered": null, "current_tier9_summ_delivered": null, "days_number_current_calendar": null, "days_number_next_calendar": null, "days_profile_current_calendar": null, "days_profile_next_calendar": null, "drawn_v_a_max_n1": 3669, "message1": "PAS DE MESSAGE", "message2": "", "power_threshold": 6, "relais": 64, "site_id": "XXXXXXXXXXXXXX", "software_revision": 2, "start_mobile_point1": 0, "start_mobile_point2": 0, "start_mobile_point3": 0, "status_register": "00DAC801", "stop_mobile_point1": 0, "stop_mobile_point2": 0, "stop_mobile_point3": 0 }
Same here like @mmorelon .
My current_summ_delivered recently got null also like in his log.
Same problem for me after changing mode from historique to standard.
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days
Hi This issue is still happening… Hello @Koenkk how could we help fixing this ? My knowledge is limited but I am willing to test :)
Removing "NJOURF+1" from the Tic command whitelist then restart Z2M seems to solve the issue.
Removing an attribute that is supposed to return a value is not a solution but a workaround. It would be the same as telling someone "you have a car with electric windows, but don't use it otherwise your car won't work at all, here is your fix"
It should be possible to read this attribute since other coordinator softwares (Jeedom, ZHA) are perfectly able to read it.
This attribut is useless and can return an empty value in function of your provider. The NJOURF+1 attribute corresponds to the next day of the NJOURF attribute which is the « Number of the day in the week of the provider’s calendar ». This kind of attribute is part of the Enedis TIC definition but is not mandatory et can return an empty value while not all providers use it depending of your contract.
Since I requested to add the « Standard - Heures Super Creuses » Tarif on the ZLinky Z2M configuration which exclude the NJOURF+1 with other useless parameters (I.e. empty), my installation works perfectly with Zlinky + Z2M + HA and Total Energies provider.
Maybe Z2M do not like attribute with « + » char… I don’t know… you are free to inspect the code of Z2M or the Zlinky firmware to find a solution.
This is not a bug fix but a workaround (and only a comment) ! Next time, I will not lose time to help people to not have this kind of comment…
What happened?
After connecting a Lixee Zlinky to my Zigbee cluster, Z2M will fail to do anything related to MQTT if :
Creating a flood of "Not connected to MQTT !" or sensor update publish errors
The issue won't disappear until I remove the device from Z2M
Also, lots of exposed entities are missing from Home Assistant.
What did you expect to happen?
To be able to rename the device and change its configuration without crashing the communication with MQTT
How to reproduce it (minimal and precise)
Zigbee2MQTT version
1.33.0
Adapter firmware version
20210708
Adapter
Sonoff Zigbee dongle plus
Debug log
No response