This is a practical solution. I will start from "Why is this function needed" and directly combine it with Thingboot's interface documentation to write a more down-to-earth development guide.

1. Why do you want to do this secondary development?

Let’s talk about the scene first. 60A circuit breakers are generally used in factories, farms, charging piles or high-power equipment.

If at 2 o'clock in the middle of the night, the fan circuit of one of your farm tripped, or a large charging pile was overloaded, if no one knew about it, the losses could be huge that night.

So, our purpose is simple:When this circuit breaker is triggered for protection (tripping) or detects an abnormality (such as overload, excessive temperature), it will no longer just cut off the power and be done with it. Instead, it will take the initiative to "speak" - take the initiative to send you WeChat, call you, or push it to the attendant.

2. The core idea of ​​this development (focus on the key points)

To achieve this, to put it bluntly, let Thingboot's "cloud" be your microphone.

Thingboot’s equipment has a very good feature:Equipment proactively reports. As soon as the status of the circuit breaker changes (for example, from closed to open), it will immediately push the message to your server.

So we just need to handle this receiving process:

1. monitor: Your server has to open a door, waiting to receive the "bad news" from Thingboot.

2. judge: After receiving the message, check whether it is a normal switch operation or whether it is really faulty (overload/leakage).

3. notify: If there is a fault, call the WeChat, DingTalk or email interface to notify the specific person.

3. Let’s do it: step by step development

Step One: Preparation

1. I have one in handUNI-DLQ-M-60A-POr a smart circuit breaker of the same series, and make sure it is connected to WiFi (the blue light is always on, indicating OK).

2. Log inThingboot console.

3. get yoursAppIDandAppSecret(Password), these two things are equivalent to your keys to the cloud..

4. Prepare a server with a public IP or domain name (if you use an intranet penetration such as peanut shells, it will work, but for a production environment, use a cloud server, which is more stable).

Step 2: Configure message push (let the cloud find you)

You need to go to the backend of Thingboot and tell the platform: "Hey, if there is a problem with my device, please send the message to my server address."

• Method 1: HTTP push (recommended for novices, simple and intuitive)

  • In the "Message Push" setting of the console, fill in your interface URL, for example:http://yourdomain.com/api/device/callback.

  • After setting it up, every time the device reports a status in the future, Thingboot will post data to your address.

• Method 2: MQTT subscription (suitable for high concurrency)

  • If you are a veteran, you can also use MQTT. Thingboot supports MQTT direct connection, with lower latency than HTTP. Just subscribeapi/{AppId}/message/stateJust this theme.

Step 3: Parse the data sent from the circuit breaker

When the circuit breaker trips, Thingboot will send a JSON packet similar to the following to your server

How to determine if it is a "fault" rather than a "manual shutdown"?

• If someone manually clicks "Close" on the APP, the device status will also becomepower:0.

• If the trip is caused by overload, the device usually comes with a fault identification.

Small:You can write the judgment logic like this to make the alarm more accurate:

Step 4: Perform active control (remote closing)

Sometimes the circuit breaker trips and after troubleshooting, people are too lazy to rush to the scene to push the circuit breaker. At this time we can close the switch remotely through the interface.

You can make a simple Web button and execute the following logic after clicking it (Bash script example to help you understand the principle):

Note: If it is a metered version, closing ispower:1, if it is multi-channel, it may bepower1:1, take a detailed look at the product manual.

4. Advanced gameplay (making your system smarter)

Now that the interfaces are all connected, it would be a bit wasteful to just make a simple trip notification. Based on Thingboot’s open capabilities, you can also perform these functions:

1. Power statistics report: This circuit breaker is metered. It can report voltage, current, and power regularly. You can store these data into the database and generate daily electricity consumption reports. It is clear at a glance which machine is consuming abnormal power.

2. Automatic reclosing: For example, for some instantaneous power grid fluctuations (power swings), you can write a logic: after detecting a trip, wait 5 seconds and automatically try to close once; if it trips again immediately after closing, it means it is a permanent fault, no more attempts will be made and a serious alarm will be issued.

3. Linkage control: For example, if you make a WeChat applet and group the circuit breakers of "My Office" and "Conference Room", you can click "Full Off" after get off work.

5. Guide to avoid pitfalls

When engaging in secondary development, there are several pitfalls that I will tell you in advance to avoid stepping on them:

• Signature calculation: The signature rule of Thingboot ismd5( md5(AppSecret) + ts ). Be sure not to reverse the order, andtsIt is a timestamp in seconds, not milliseconds.

• frequency limit: The control frequency limit of Thingboot for a single device is1 time/second, if your program has an infinite loop and sends commands frantically, your IP will be temporarily banned..

• Network stability: The circuit breaker uses 2.4G WiFi. If the WiFi signal in the on-site environment is not good, the connection will be dropped. Add a "device offline" notification to your alarm logic to alert you of network problems.

Summarize

Taking advantage of the open capability of Thingboot 60A circuit breaker, you only need about a few dozen lines of code (or even less) to build an independent "fault alarm system".

The core logic is:The device triggers -> the cloud calls back your interface -> your code sends a message. After this solution is put into operation, even if the computer room trips in the middle of the night, you will be woken up by a phone call immediately, and you will not have to wait for customer complaints to find out that the equipment is down.