Add RSSI and SNR data to message events #94
Conversation
- Enhanced message events to include RSSI (Received Signal Strength Indicator) and SNR (Signal-to-Noise Ratio) data - Modified api.py to extract and include RSSI/SNR values in event data - Updated const.py with new event data fields - Enhanced logbook.py to handle and display RSSI/SNR information in message logs
Update to alphabetically order data_attr imports
|
RSSI / SNR will not be displayed in logbook message logs because Is this intended? |
|
Okay so that may be a miswording on my part. The goal was to get the message_log events so that I can harvest it through node-red/automations. I'm very green when it comes to HA integrations so my bad for that. Would it be your preference that the data also be added in logbook entries? |
|
I think having RSSI & SNR rendered in logbook messages is probably too much information and only relevant for only few people. Adding them only to the event might be a middle ground (so that people using custom rendering options for those events to display if needed) One issue I see with having RSSI & SNR info in the logbook events is that with next release, there will also be logbook entries for messages that are sent from the integration (#59), those event won't be able to have RSSI and SNR value, so I'm wondering if this will break your automation and we should not add RSSI & SNR to the message_log at all, because not all those events will have values. Having RSSI & SNR values for api events I see no issues. |
|
Makes sense to me. I'm content with just in the message event if you're comfortable with that. |
Fix message event issues, packet.py was not synced to branch from local changes resulting in errors on messages.
|
If it is fine for you to rely on api events, and not the message log events (they give you more control), then it is better to only add RSSI and SNR there and not have it in message log event. With the recent changes regarding message log (to include outgoing messages), those events are now rather particularly for logbook only and should ideally not be used for other purposes. If there is need for a higher level event about messages when api events are not convenient enough, I think we can rather introduce such an event so that there is no need to use message log events for logbook |
Apologies for the duplicate PR.