1. Why write this?

Many people get confused when they hear "secondary development" and "interface docking" and think that they need to have a professional development team. It's actually not that exaggerated.

Let's take the open interface of Thingboot as an example. It is quite simple, it is just an HTTP request. As long as you can send a POST request, whether it's Java, Python or PHP, or even if you use a visualization tool like Node-RED, you can do it.

Today’s article is dedicated to talking about how to connect the 40A timing control circuit breaker on the market (which supports Modbus) to the Thingboot platform to achieve remote parameter changes and remote switching. Let’s try to talk less nonsense and talk more about practical ideas.

2. What’s going on with the hardware?

2.1 What does a 40A circuit breaker look like?

This kind of circuit breaker is generally used in factories, greenhouses, charging piles, distribution boxes and other places. It has a rated current of 40A and can carry a load of about 8000W.. Features are:

• Can open and close remotely: You don’t have to go to the scene to break the handle.

• Can be controlled regularly:Set what time to turn on and what time to turn off

• Can read power data: Voltage, current, power, etc.

• can protect: Automatic tripping for overvoltage and undervoltage

2.2 The communication interface is Modbus

Most of these circuit breakers on the market useRS485 + Modbus RTU protocol. In other words, it is not directly connected to the Internet and requires a gateway to act as a "translator" - to convert Modbus into HTTP or MQTT that Thingboot can recognize.

Tip: When buying, ask the manufacturer clearly whether it supports Modbus and whether it provides a register address table. Some cheap products have castrated these interfaces, so it is impossible to play.

2.3 Common register addresses (probably looks like this)

Different manufacturers have different addresses, but the principles are similar. Let me list some common ones for you to watch and play with:

The key is to ask the manufacturer for your address sheet., which is the basis for docking.

3. How to play here in Thingboot

Thingboot's open interface is very friendly, it is a standard HTTP API.

3.1 The interface of the control device looks like this

POST http(s)://api.thingboot.com/{AppID}/device/control/?sign={sign}&ts={ts}

The parameters are placed in the Body in JSON format:

It's that simple,power:1Just open it,power:0Just close.

Note: Returning 200 only means that the platform has received the instruction, but does not mean that the device has actually executed it. If you want to confirm the device execution results, you have to receive push messages..

3.2 What commands does Thingboot recognize?

Thingboot’s own smart circuit breaker products are directly recognizedpower、resetthese commands. But if you are using a third-party Modbus circuit breaker, Thingboot will not recognize your "read register 0x0001" command - a gateway is needed in the middle for translation.

4. Overall solution structure (core!)

This is the most critical link. It may be easier to understand by drawing a picture. I will try to describe it in words:

Your server/cloud platform ←→ Thingboot API ←→ Gateway (DTU/4G RTU) ←→ 40A circuit breaker (Modbus)

The data flow is roughly like this:

1. You send it to Thingboot API:{"device":"breaker_01","order":{"action":"close"}}

2. Thingboot pushes the command to the gateway

3. The gateway translates into Modbus commands:01 05 00 00 FF 00(Close)

4. circuit breaker execution

5. The gateway reads back the status and then reports it to Thingboot

6. Your system receives a status update

So the core question is just one: How does the gateway know that "action:close" corresponds to "write register 0x0000=1"?

4.1 Solution A: Use programmable gateway (recommended)

Buy a 4G DTU that supports custom scripts (such as Renren or Hongdian brands) and write a Lua or Python script in it:

Then on the Thingboot platform, just issue custom commands directly to your gateway.

4.2 Option B: Build a conversion service yourself

Set up a simple service on your cloud server. The process is:

• Receive Thingboot's webhook (device online and offline, command callback, etc.)

• According to the received command, read and write the circuit breaker register through the Modbus TCP interface of the gateway

• Actively push the read data to Thingboot (using the device data reporting interface)

The advantage is that it is flexible, but the disadvantage is that it requires a server to run.

4.3 Solution C: Use edge gateway (industrial scenario)

In places such as factories and campuses, edge computing gateways (such as human and Fanyi) can be used. Run Node-RED directly in the gateway, drag and drop to convert Modbus to MQTT, and then connect to Thingboot. It is easy to maintain and can be understood by people on site.

5. Specific implementation of remote parameter change

This is what you are most concerned about - "remote parameter configuration management", which is actually writing registers remotely.

5.1 Change the overvoltage threshold

For example, in summer, when electricity consumption is high, the grid voltage is low and the circuit breaker keeps tripping, you want to adjust the overvoltage threshold from 250V to 265V.

After receiving it, the gateway performs Modbus writing and then replies to you whether it is successful or failed.

5.2 Configure scheduled tasks

You want the circuit breaker to close at 8 a.m. and open at 6 p.m. every day:

After the gateway receives it, it writes the time into the corresponding timing register (usually 0x6D01 to 0x6D0E).

5.3 Read real-time data

Read voltage, current, and power regularly or on demand:

After reading it, you can push the data to the platform through Thingboot's device data reporting interface, and you can see it on the console.

6. Several pitfalls that are easy to step on

1. Don’t make mistakes in the wiring of the gateway and circuit breaker.

RS485 has two lines A/B, A connects to A, B connects to B, do not cross. There is also an address dialing code that needs to be set correctly. The default is usually 1..

2. The baud rate must be consistent

There are many cases where the circuit breaker defaults to 9600, 8 data bits, 1 stop bit, and no verification, but it is best to confirm. The gateway must be configured the same..

3. Timeout processing

Modbus communication has the risk of timeout, especially where the signal is poor. :

• Set a reasonable timeout on the gateway (e.g. 3 seconds)

• Use the asynchronous confirmation mechanism after the command is sent, don’t wait.

4. Security considerations

Circuit breaker control involves strong electricity, and the interface must be verified for permissions. Use signature mechanism on Thingboot platform, don’t run naked.

7. Summarize

The entire docking process can be summarized as follows:

1. Confirm hardware: The 40A circuit breaker supports Modbus RTU, get the address table

2. Prepare gateway: Buy a 4G DTU or edge gateway that supports custom scripts

3. Write conversion logic: Translate Thingboot commands into Modbus register reading and writing in the gateway

4. Register device: Add the gateway device in the Thingboot console and get the device ID.

5. Start calling:Through the core step/device/controlInterface issues commands

6. receive feedback: Confirm the execution result through message push

To be honest, it would be troublesome to reinvent the wheel yourself, but with Thingboot’s interface and ready-made gateway, most of the work is to write a few conversion scripts. One person can basically get through it in a day or two.

If it is only used in a small range (within a few dozen points), option B is the most flexible. If it is an industrial plant or park that requires long-term stable operation, choose Plan C, which has much higher on-site maintainability.

If you have any questions, feel free to ask them in the comment section.