Send to channel

[asjmcguire]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

I use the MQTT JSON feature at the moment to broadcast weather data on 2 channels, primary for less frequent weather updates, and road conditions when the temperature drops below 3C. And a dedicated channel for broadcasting the current conditions every 30 minutes. There only appears to be the ability to broadcast to another Node at the present moment, in this integration.

Describe the solution you'd like

The ability to broadcast to any configured channel for the selected node.

Describe alternatives you've considered

I will have to continue using MQTT for the time being.

Additional context

Requires ability to broadcast to channel index. Eg 0 or 2 in my case.

[broglep]

Thanks for reporting and helping prioritize different features. There are already entities for the individual channels, but so far there is now way via home assistant to send to a channel.

One idea is to offer the channels also as notify target (same as all nodes). Another option is to extend send_text service or introduce dedicated service.
Unfortunately device actions don't work that well as channels are not devices themselves.

Do you have a preferred way of integrating that functionality?

[asjmcguire]

Do you have a preferred way of integrating that functionality?

So from a GUI standpoint, I thought it would make the most sense for the channels you have already configured on the node, to appear in the dropdown for the target.

However, as this may be more complicated for you to implement, in the short term at least, I'd be more than happy to switch to YAML and use something like channel: 0 to indicate that I intend this to be a broadcast message rather than a direct to node message.

Attached is example automation code I currently use for sending to the node via MQTT:

{% if trigger.id == "MeshtasticSixHour" %}
  {% set chnum = 0 %}
{% else %}
  {% set chnum = 2 %}
{% endif %}  {% set t = states('sensor.tmpl_outside_temperature') %}  {% set h = states('sensor.tempest_st_00015638_humidity') %} {% set w = states('sensor.cc_30_min_gust') %}  {% set lux = states('sensor.average_daylight')|float(0) %} {% if lux > 999 %}
  {% set l = ((lux / 1000)|round) ~ "k" %}
{% else %}
  {% set l = lux|round %}
{% endif %} {
"channel":{{ chnum }},
"from":3662959096,
"type":"sendtext",
"payload":"T:{{ t|round(1) }}c Hum:{{ h|round }}% Gst:{{ w }}mph UV:{{ states('sensor.tempest_uv_average') }} Lux:{{ l }}"
}

[broglep]

So from a GUI standpoint, I thought it would make the most sense for the channels you have already configured on the node, to appear in the dropdown for the target.

Are you referring to automation UI where you select currently the device as target or are talking about the Developer Tools -> Actions (meshtastic.send_text service)?
For services/actions it is easy doable to offer the entities as target (the new notification system also works that way)

[asjmcguire]

The "to" field on the automation editor after you have selected the node that you are sending the message from.
I guess an easy way to do it on the GUI would be to have a tickbox for the node you intend to send the message to, and another field with a tickbox that is just to type in a channel number. Then you can easily just type the channel number, rather than having to have a dropdown of the channels, as I assume if you have multiple nodes added, it will make more complicated since taking my example - borderswx is channel 2 on the main node, but might be channel 1 on another node. So it's probably easier to allow someone to just directly state the id of the channel they want to broadcast from?

[broglep]

Ok, thanks for the clarification, so you are directly using the action/service in your automation, and not device action.

The send_text action actually supports not only home assistant device id as to value, but also node number or the user id, but that is not really exposed via UI and UI does not offer that much flexibility. Doing similar with with channel will be possible as well.

I had to change the structure of some internal events to be more explicit for the current feature I'm working on to store direct messages and channel messages, so I might end up introducing similar change for the send text service as well, this would exactly be as you describe it, separate fields for node or a channel as target (and probably supporting both entity / device ids as well as numeric ids)

Do you refer to the channel index (node local concept) or the channel hash (mesh protocol concept)) when you are suggesting to use as it as identifier?

You are right that the channel a tricky thing as the channel numbers don't necessary have to match on different devices. The only real unique identifier for a channel is its PSK, so channel index is no good way to identify a channel when you are not at the same time exactly specifying via which gateway node you are sending a message. The channel hash might work as short version of the PSK that could be used by a human, but that will be probably confusing as well as you can't really distinguish a channel index from a channel hash as a human.

I think the safest way will be that via UI you are only able to select channel entity, such an entity belongs to a device and you can be sure that it is sending on the correct channel. This pre-determines the gateway node you are sending from, but that shouldn't be such a big issue.

Due that complications with channels, it might not be well suited for the notify platform, as this integration's concept for notify targets is that they are independent of the gateway, but maybe with notify entities there would be a way to use PSK or channel hash as the identifier

Depending on how much the use cases will differ in the end between private message and channel message I might end up introducing two separate actions/services.

[asjmcguire]

I'm working on to store direct messages and channel messages,

Ooooh yay!

Do you refer to the channel index (node local concept) or the channel hash (mesh protocol concept)) when you are suggesting to use as it as identifier?

I don't know how the Meshtastic Python API works for this part, so that's really up to you to decide which is the easier method, from the human point of view though, simply using the channel index makes the most sense. Eg 0 - 7

I provide a screenshot of my current dashboard which I populate via MQTT - so you can see the things I am most interested in.

[broglep]

Nice dashboard! As far as I can tell the packet types metrics are the only ones that are currently not available (although there are some slightly related metrics for the gateway: packets received, relayed, sent, duplicate, etc)

I've just released new version 0.3.0 that comes with quite some improvements, including support to send to channel.

I have kept meshtastic.send_text service/action for the time being and added option to specify channel as well. It is still used internally for certain use cases, but I would not recommend using it in automation (I don't consider it as public interface and there could be breaking changes in the future). For your use case of sending message to a channel, I'd recommend to use the new meshtastic.broadcast_channel_message action or use the notify.send_message with channel notify entity (the later maybe bit less final, unique id / entity ids might still change, but so far looks pretty good)

[asjmcguire]

I will updated tomorrow - during daylight. My Home Assistant gets a bit upset when I update at night, because the Solar inverter powers down when there is no solar, and so all my solar related entities stay as Unavailable. I'll give the update a try and let you know how I get on with it. Thank you. I hope you got the donation earlier.

[asjmcguire]

Getting a lot of

2024-12-24 23:45:00.060 ERROR (MainThread) [homeassistant.components.automation.meshtastic_weather_broadcast] Meshtastic Weather Broadcast: If at step 1: If at step 1: If at step 1: Error executing script. Error for call_service at pos 2: Not connected
2024-12-24 23:45:00.060 ERROR (MainThread) [homeassistant.components.automation.meshtastic_weather_broadcast] Meshtastic Weather Broadcast: If at step 1: If at step 1: Error executing script. Error for if at pos 1: Not connected
2024-12-24 23:45:00.060 ERROR (MainThread) [homeassistant.components.automation.meshtastic_weather_broadcast] Meshtastic Weather Broadcast: If at step 1: Error executing script. Error for if at pos 1: Not connected
2024-12-24 23:45:00.061 ERROR (MainThread) [homeassistant.components.automation.meshtastic_weather_broadcast] Meshtastic Weather Broadcast: Error executing script. Error for if at pos 1: Not connected
2024-12-24 23:45:00.061 ERROR (MainThread) [homeassistant.components.automation.meshtastic_weather_broadcast] Error while executing automation automation.meshtastic_weather_broadcast: Not connected

If I go in to the automation and manually run the action, it will immediately come back and say "Not Connected" for the first few times I try to run the action, and then finally will succeed.
I'm connected over IP right now, I tried Bluetooth too, but could never get it to connect even after removing the PIN, and then I tried serial, which does work, but stopped updating the data once the uptime reached 497 seconds, and additionally if I try to add one of the nodes it can see from the configure button (like I do when connected over WiFi - which works fine) - all entities become unavailable and it never adds the node.

You might also like to know though - there were many log entries complaining about the platform not using unique id's - I will open a bug report about that.

When it is complaining that the gateway is not connected in the automation traces, there is no sign in the actual device details screen that the gateway is really disconnected, uptime continues to climb and the entity saying it is connected, continues to say it is connected.

[broglep]

Did you use notify.send_message or meshtastic.broadcast_channel_message?

I already experienced similar thing when using notify.send_message with a channel and multiple config entries / gateways and few of them not working (but that should kind of remediated now as notify.send_message does try all gateways now).
But meshtastic.broadcast_channel_message does not yet support this, so when you are not specifying from, you can always end up with the same non-working gateway node to be used.

You can try to enable debug logging for the integration? I occasionally see continuous reconnect loop with TCP connection that I can only recover manually by either restarting the integration or the meshtastic node, such a reconnect loop is visible in the debug logs, that could be another cause for that not connected error. As the initial connect & full read-out of all data always succeeds before the connection is dropped, it can appear on the surfice that still everything is working.
Still have to figure out how to automatically recover in such a situation, one of the issues is that the meshtastic node does drop previous tcp connections if it gets a new one, so if something is stuck and for some reason multiple connections are open / in-flight, you end up in such a situation.

Bluetooth and serial are indeed rather unstable compared to TCP based on my tests. Bluetooth stability highly depends on the dongle used and for serial it seems that sometimes the serial interface completely disappears after some time (suspect it to be a hardware / firmware issue, for that particular node bluetooth also stops completely and need to power cycle the device)

[asjmcguire]

Did you use notify.send_message or meshtastic.broadcast_channel_message?

Hi, sorry, I wasn't expecting a response over Christmas haha.
Yeah I'm using the meshtastic.broadcast_channel_message option.
I plan to tidy up my network a little bit to reduce the number of switches that traffic is passing through, in the hope that might help somewhat too. But I have to wait till the end of December for my Netgear Gigabit Switch PSU to be shipped to me.
If that doesn't help clear things up a bit, then I will enable debug logging and see what it happening.

The interesting thing about the serial interface, was that while everything stopped updating, it would still continue to send the channel broadcasts, so it was definitely still connected.

Oh, and by the way I am running the Alpha firmware released today. 2.5.17.b4b2fd6

[broglep]

Hi, sorry, I wasn't expecting a response over Christmas haha.

Won't be able to do much testing with actual devices next few days, but can help out with troubleshooting from time to time :) My long term off-grid test-setup/installation is currently pretty short on power as the snowfall has cut both power sources, so won't have much long term testing data with the newest 0.3.0 version.

I plan to tidy up my network a little bit to reduce the number of switches that traffic is passing through, in the hope that might help somewhat too.

Not sure if the network itself plays an role with that reconnect loop issue, more suspect meshtastic firmware in combination with operation system / python + the integration behaviour. Maybe bigger backoff times for re-connects will help, but will have to investigate further

If that doesn't help clear things up a bit, then I will enable debug logging and see what it happening.

You can actually also see the reconnect loop on the meshtastic node side if you have a serial log console open for that node you are connecting via tcp.

The interesting thing about the serial interface, was that while everything stopped updating, it would still continue to send the channel broadcasts, so it was definitely still connected.

Just for clarification, you mean you could still send messages via the serial interface?
In my case the the node is not able to communicate at all, but it still properly working on the mesh (receiving & relaying messages)

Oh, and by the way I am running the Alpha firmware released today. 2.5.17.b4b2fd6

I'm also testing mostly with recent alpha / beta firmwares, ranges from 2.5.11 - 2.5.17

[asjmcguire]

Won't be able to do much testing with actual devices next few days, but can help out with troubleshooting from time to time :) My long term off-grid test-setup/installation is currently pretty short on power as the snowfall has cut both power sources, so won't have much long term testing data with the newest 0.3.0 version.

Oh gosh! That doesn't sound good. It's practically a heatwave in the UK right now. We were at 14.1C today, definitely no white Christmas here this year.

Just for clarification, you mean you could still send messages via the serial interface?
In my case the the node is not able to communicate at all, but it still properly working on the mesh (receiving & relaying messages)

When I used configure to try to add one of my other nodes that the gateway could see, when the gateway was connected via serial, and the node was not added, and all the gateway entities went unavailable - messages could not be sent. The serial was as far as I can tell fully disconnected at this point. As a reload of the integration would result in a message saying failed to connect.

When I ONLY added the gateway via serial, and did not attempt to add any of the other nodes that it could see, the data stopped updating after about 500 seconds (uptime didn't continue to increase, airtime remained static etc). But messages continued to send.