serial-port | A set of C++ classes to easiliy handle serial ports | SDK library

The Modbus specs describe the protocol and are worth a look. I use this online Modbus parser when I want to quickly parse a command; it's output for the string of bytes you give (20 05 00 00 FF 00 8A 8B) is:

Part of Data Package Description Value 20 Slave address 0x20 (32) 05 Function code 0x05 (5) - Write Single Coil 00 00 Output address Physical: 0x0000 (0) Logical: 0x0001 (1) FF 00 Output value On 8A 8B CRC 0x8A8B (35467)

The slave address indicates which device on the bus you wish to communicate with. This is set on the device (you cannot just add devices and expect things to work). The method used to set slave ID's differs from device to device (some have a utility to do this, some use switches or settings via their own user interface, and some have this hard coded). Your device (Ebyte MA02-XACX0440) defaults to 32 but this can be changed using the DIP switch on the device (this is covered in the manual).

You are using function code 5 - 'Write Single Coil'. Coils are bits so can be on or off.

The 'output address' indicates which coil on the device you wish to write to. The meaning of this address varies from device to device (generally there will be a table in the documentation that explains this). For your device this is in table 7.1 ("Register list") in the manual.

The value is what to write. For the 'write single coil' function this must be one of two values:

value meaning 0x0000 Off 0xFF00 On

All other values are invalid. However many libraries (incluing pymodbus) will handle this detail for you allowing you to pass True/False.

Putting this all together you will need something like:

Your main concern is to be thread safe, when You are updating GUI from another running Thread.
To achieve this, we can use .after() method, which executes callback for any given tk widget.

Another part of Your request is to use Threaded serial reader.
This can be achieved by using ReaderThread accompanied with Protocol.

You can pick two protocols:

• raw data reader protocol, which reads data as they come
• line reader protocol, which enables us to read lines of data

Here is working code example, with two protocols mentioned above, so You can pick which one suits You. Just remember, that all data coming from serial port are just raw bytes.

Swallow standard error to avoid the extraneous output:

I figured it out myself. Turns out, like John Hanley kindly pointed out, that I had imported a virtual machine. And I guess this bucket was created as part of that import.

The reason I had imported it was trying to set up Meilisearch on a VM following their guide here: https://docs.meilisearch.com/create/how_to/gcp.html

I ended up deleting the VM since I didn't use Meilisearch, but I guess this bucket was left behind.

I'm going to delete it since I don't even have the VM left, and can't think of a reason why I'd need that bucket. (if this turns out to be a terrible idea and everything breaks, I'll be sure to come back here and post about it)

It was a driver issue.

Most old models USB to Serial adapters are presenting problems on Windows 10. After trying several drivers, I found this one that solved my problem.

It is linked to a Youtube video in a language that I do not understand. However, the steps are easy to follow. After downloading the driver and following the steps, it works just fine.

It looks like there is a Bluetooth Serial Port Profile (SPP) server running on the sensor and so the SPP client on the Raspberry Pi connects and exchanges information successfully.

Python sockets for Bluetooth SPP on Windows was only introduced in Python 3.9 so you will need a recent version of Python on your Windows computer.

However, if it has connected, then maybe you need to go hunting for the serial port it has connected it to. Maybe the following will help: https://www.instructables.com/Raspberry-Pi-Bluetooth-to-PuTTY-on-Windows-10/

However a more typical setup would be that the Raspberry Pi would be a bridge between the sensor and the network. This means that the value from the sensor goes to the RPi by Bluetooth. Then the RPi makes the sensor data available over WiFi/internet via a website/socket running on the RPi.

As a side note, you could be a little more efficient with your unpacking of the data. For example:

I found out the issue. I am trying to update the UI from another class by creating a new object for the UI. The actual UI was created from void main using a different object.

I resolved it by passing the existing object to the class that was calling the UI update function.

Thank you for your help people.

PyModbus is not receiving a response.

If you have access to an oscilloscope, this is the moment to use it. There are soooo many things that can go wrong with Modbus-RTU.

Make sure you know what you are doing with the electrical wiring, familiarize yourself with RS485 biasing and termination.

Possible causes:

• request sent to wrong serial device/interface
• device uses different baudrate or serial settings
• device can hear you allright but has a different slave ID configured, so it doesn't respond
• wrong wiring, grounding issues
• RS485 electrical problems, most notably the master must be biasing the bus, usually via a resistor that you have to solder/enable
• Bus termination resistors are required for correct voltage levels (sometimes they are already built-in, more often you need to enable them, with some luck may work without)
• Master still driving the RS485 bus while the slave is responding. (If you do not have a dedicated RS485 driver, the bus may end up being asserted/deasserted by unreliable software timers. Some devices allow you to configure a response delay as a workaround.)
• Master not driving the bus at all. (Working in RS232 mode instead of RS485 mode.)
• Also, Linux might have ttyAMA0 configured as a serial console for boot/kernel messages. (This is unlikely to cause your current problem, just something else to watch out for.)

Final piece of advice: if you have the option to use Modbus-TCP instead of Modbus-RTU, do that instead. This replaces all the RS485 electrical headaches which IP-configuration headaches, for which you can use over-the-counter medication.

You should be able to utilize ModemManager to get the GPS location instead of getting it directly. This way you can avoid using the same serial port from two services.

There is documentation on how to do this from the command line using the mmcli tool in the ModemManager manpage: https://www.freedesktop.org/software/ModemManager/man/1.0.0/mmcli.8.html#lbBC

There is also a libmm-glib library which you should be able to use from Python via GObject Introspection without running the command line tool.