Serial port issues

Hello, new to Mashtastic. I am trying to write some serial port communication and golang and seem to be running into a few issues.

The first issue I am seeing is that whenever I communicate to the serial port, the device screen then locks up and stays locked even after I disconnect the serial port. It seems the only way to fix it is to reset the device.

The second issue is that there are many settings that don’t not seem too write to the device. Some examples are the Wi-Fi settings and the user settings.

Here is the code I wrote:

Thanks in advance.

1 Like

re: screen disabled while API is in use
That was by design, but others have asked to turn this ‘feature’ off as well. So probably it was a bad idea ;-). Would you mind putting in a bug for meshtastic-device and after 1.0 is finished we’ll (probably me :wink:) fix this.

re: screen stays disabled even after you stop using the API
Internally we have EVENT_SERIAL_DISCONNECTED which is supposed to cause this but nothing is currently publishing that event. I’ll fix that at the same time I fix the other thing.

re: written changes are not accepted
can you elaborate on this? Are you saying you change something like ChannelSettings.Name but then if you disconnect and reconnect, you don’t see the changed value? If so that’s a bit puzzling. Perhaps you can try running “meshtastic --debug --setpref test” and watch what the python tool sends across to compare?

Thanks for getting back to me. I will file issues for the serial port as requested.

The issues with writing configs seem to be:

In radio_config->user_preferences the WiFi settings look look like they are not updating. I’m not well versed with C++ but does this mean the WiFi settings can not be changed yet:

As far as the user goes, I can’t tell if it is working because user can only be sent as a to-radio message, but you can’t view the current setting in a from radio message, if I’m reading the proto file correct.

You can. It is a (poorly documented? :smirk:) requirement for using the API that the client start the flow by sending a start config message and then the device will send all the initial state a client needs - including the radio config.

For an example, try running “meshtastic --info --debug” and you’ll get to watch the initial packet exchange from the python client does.

You also might want to look over inside the portion api - I bet the classes you will want to make for your cool Go api will be similar.

This might be useful for you. The serial API is basically identical (except one streams with extra framing and the other uses datagrams) the Bluetooth api. When the wifi code is enabled it will use the streaming API over TCP:

The python API has been immensely helpful. I’ve been modeling the Go client after it. I have it send the want config id message first upon connection to the serial port then the reply asynchronously stores the config to a property of the mesh object.

I was tried to reply with a link to the code on github showing this, but now for some reason my posts are being flagged as spam.

Looks the system restored posting. Here are the github links to the relevant sections:

The reply asynchronously handled and puts the config as a property to the mesh object:

Ah, now I see the part about where to get the user info:

So I can set the name and when I get the list of nodes again, it changes:

my_node="my_node_num:3045257816 has_gps:true num_channels:13 region:“1.0-US” hw_model:“tbeam” firmware_version:“0.7.10” packet_id_bits:32 current_packet_id:1613480412 node_num_bits:32 message_timeout_msec:300000 min_app_version:172

node=“num:3045257816 user:{id:“4321” long_name:“lora2” short_name:“L2” macaddr:”\x8c\xaa\xb5\x82\xf2X"} position:{latitude_i:xxx longitude_i:-xxx altitude:xxx battery_level:100 time:1594256178}"

However, when I reboot the device it reverts the name back to a previous one:

node=“num:3045257816 user:{id:”!8caab582f258" long_name:“Lora3” short_name:“L” macaddr:"\x8c\xaa\xb5\x82\xf2X"} position:{latitude_i:xxx longitude_i:-xxx altitude:xxx battery_level:100 time:1594256177}"

yeah - changes to the node db/config are only written to flash when the device enters deep sleep (i.e. we weren’t planning on users pressing reset ever). If you just press the reset button the changes will be lost. Hmm - we should probably add a disconnect message an API client can send to indicate it is done talking to the the device (related to your original post) and when that message comes in we should go ahead and write to flash just in case.