No event logs after updating to 1.37.1-1

[shalak]

What happened?

After I bumped the Z2M to 1.37.1-1, the log (even in DEBUG) no longer shows the events sent from devices. I see the the errors, joining the network, enabling/disabling Join All, but no events from the devices.

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.37.1-1

Adapter firmware version

0x26780700

Adapter

ConBee2/RaspBee2

Setup

HA x86, as add-on

Debug log

No response

[pcb1962]

I'm seeing the same. Previously my syslog contained 'MQTT publish:' events at Info level, eg:
MQTT publish: topic 'z2m/kitchen/thp', payload '{"battery":83,"elapsed":2,"humidity":62.61,"last_seen":1715468544196,"linkquality":83,"power_outage_count":23827,"pressure":1011.4,"temperature":21.45,"voltage":2975}'
I'm no longer seeing those, no messages since 'Zigbee2MQTT started!
Switching to Debug log level I see some 'MQTT publish:' events, but not all.

[wastez]

As far as I read in the docs the mqtt messages are disabled by default on the new version and need to be enabled if needed, so no bug, it’s a feature.

[shalak]

As far as I read in the docs the mqtt messages are disabled by default on the new version and need to be enabled if needed, so no bug, it’s a feature.

Can you share the docs you read? There's nothing about the MQTT events in the documentation I saw

[Andrik45719]

https://www.zigbee2mqtt.io/guide/usage/debug.html#enabling-logging

[shalak]

That's about enabling debug logging, not about enabling event logging. Even on debug, not all the events are logged (and debug logs are too noisy anyway)

[wastez]

@shalak
There is no way to enable it like before.
If you really need it you need to enable debug mode and set the option to get it to the frontend if you want to have it in the Frontend too.

But there is a reason, you don’t need it if you’re not debugging and it would need performance all the time for nothing.

Edit:
Of course you can enable the debug mode + the option and use filters that you just get what you want.
But I don’t see why it should be needed all the time if you are not debugging.

[shalak]

That's a bummer, I consider this a major downgrade when it comes to user experience.

I was using the logs to see the exact payloads and JSON data types of events to work with them e.g. in NodeRED. Not really a "debugging" scenario. With debug logging, I'm getting hundreds of messages every seconds, it's very hard to work with useless.

you can enable the debug mode + the option and use filters

What filters would I need to use to get the previous behavior? ^MQTT publish: .* should work?

[wastez]

Ok you are using it in node red.
I‘m sure the coder doesn’t thought about this possibility, he just thoughts about not needed performance, because if you are not debugging and not using it in node red it’s not necessary.
The filter belongs what is displayed in log and what you need.
I thought about ignoring everything what you don’t need like in the example.
@Nerivec Maybe a own node red logging option?

Edit: doesn’t have node red better possibility’s to access mqtt information? As far as I know there a special option for it?!

[shalak]

Edit: doesn’t have node red better possibility’s to access mqtt information? As far as I know there a special option for it?!

It does, but it was easier to work with Z2M GUI, especially since it is a source-of-truth.

[Nerivec]

Next release should provide support for finer customization: #22619 (docs preview)
MQTT Publish lines are very verbose, especially in larger networks, which results in high MQTT traffic. It was lowered to debug for that reason (excluded from MQTT publishing). But it seems some users were using these lines in day-to-day stuff.
Next release will allow to choose the level logged for MQTT stuff (and other namespaces), so if someone wants to reduce the traffic, they will be able to do so with:

advanced:
  log_level: info
  log_namespaced_levels:
    z2m:mqtt: warning

Please note that using logging for any kind of automation is definitely not recommended, as the format of messages, or the messages themselves may change without notice.

[francisp2]

I simply use mqtt explorer to see the mqtt messages if needed
https://mqtt-explorer.com/

[pcb1962]

I simply use mqtt explorer to see the mqtt messages if needed https://mqtt-explorer.com/

I use mosquitto_sub in the same way, but that doesn't help when you want to see when the last message was sent from a device that has gone missing, which is what I frequently use the mqtt event log for.

[github-actions]

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