CATALOG

This is a solution for integrating Thingboot smart smoke detectors. I will combine the characteristics of product manuals and open interfaces to help you sort out the entire implementation process in a more down-to-earth and colloquial way.

Dear developers and project leaders:

Hello everyone!

When we work on projects, whether it’s smart factories, shared spaces (such as study rooms, tea rooms), or warehouse management, we have two biggest headaches:One is the fear of catching fire (safety), and the other is the fear of wasting electricity (energy saving).

Traditional smoke alarms only "squeak". Even if the person is not present, you won't be able to hear the screams. Moreover, it is a complete "stranger" to the switch and exhaust fan, and cannot be linked to each other.

Today, let’s talk about how to usecore stepThe smart smoke detector (UNI-CGQ-YW) and its open interface, useAbout half an hour of code, solving these two pain points together.

Step one: What’s so special about this thing? (hardware selection)

Let’s look at the hardware first. This detector has several features that make it ideal for integration:

  1. Direct WiFi connection, saving money on gateway: It does not need to buy an additional gateway, just plug it in and connect to WiFi. This is particularly friendly to us in controlling project costs..

  2. Interface "fool-like": Thingboot's devices all use the HTTP protocol. No matter your backend is Java, Python or Node.js, or even a low-code platform, as long as you can send POST requests, you can play with it..

  3. Private deployment: If your customer’s data does not want to be accessed on the public network, or there is no external network at the site (only an intranet), it supports purely local control over the LAN, ensuring maximum security..

Step 2: How to make it "speak"? (Integrated development practice)

This is the core part. What we want to do is:"Pull" the status of the detector into your backend.

Thingboot's equipment actively "reports" data by default. In other words, as long as the smoke concentration changes, or someone presses the test button, it will actively send a message to your server.

1. Get the "signature" and get the ticket

Before calling its interface, you need to make a simpleSign. Don't be scared by this word, it is actually a small mechanism to prevent others from messing with your interface.

According to the official logic:md5(md5(your AppSecret) + timestamp).You can encapsulate a public function in the backend and dynamically generate this signature before each request.

2. Receive alarm data (uplink)

How does the device tell you the message "It's on fire"? you need to prepare oneReceive URL, configured in the background of Thingboot.

When the smoke concentration exceeds the standard, the device will send data like this:

your task: Write an interface to receive this JSON. once received"status":"alarm", your system should start working - such as a pop-up window notifying the administrator, or calling the "control interface" below to cut off power.

3. Remote silencer and self-test (downstream)

If you want to make a "silence" button in the App, or have the device perform self-checks regularly, useDown command.

Request address:http(s)://api.thingboot.com/{AppId}/device/control/?sign={sign}&ts={ts}

Request Body example (turn off the buzzer):

It's that simple, just send this JSON and the detector in the distance will stop beeping..

Step Three: "Safety + Energy Saving" Scenario (This is the trump card)

It’s not enough to see data; what we want isAutomation linkage. Here is an exampleShared study room/tea roomExample:

Scenario pain points: A guest smokes in a private room, the smoke alarm goes off wildly, other guests complain, and the boss is worried because he is out of town. Or if the guests leave and forget to turn off the main switch, the electricity bill will go up.

Solution integration logic

  1. deploy: Install one smoke detector + one in each private roomThingboot’s intelligent controller(used to break the circuit).

  2. Linkage

    • monitor: The detector detects smoke concentration > threshold.

    • Report:HTTP callback hits your server/api/smoke_alarm.

    • business decisions: Your backend determines that this private room is currently in "sold" status.

    • perform action

      • safe action: Automatically call the controller interface{"power":0}, cut off the power to the socket in the private room (forcibly powering off the charger/computer to prevent fire hazards).

      • notification action: Call core stepvoice speakerInterface, broadcast "Smoke detected in XX private room, please do not smoke".

      • Record action: Send a push message to the store manager App: "There is suspected smoking in private room No. 3, and the power has been automatically cut off."

Effect: It not only prevents the risk of fire, but also restrains customers’ uncivilized behavior and maintains the indoor air environment through the slightly punitive measure of "forced power outage".

Step Four: Guide to Avoiding Pitfalls (Talk from Experience)

In actual integration, there are a few tips that can help you avoid detours:

  1. Timeout processing:Interface returns200It only means that the command was issued, not that the device executed successfully.. If the device’s WiFi signal is not good at the time, it may not be able to receive it.: Take advantage of itAsynchronous message pushMechanism, after the device executes successfully, it will send back a confirmation message, and at that time, it will prompt the user that "power has been cut off".

  2. Regular self-test: Smoke detectors are also electronic products and can break. Create a scheduled task in your own system, for example, every Monday at 3 a.m., call the interface to let the detectorself-testAfter a while, if there is no response, it will be marked as "offline/fault", and the operation and maintenance personnel will be reminded to go to the site to take a look.

  3. False positive filtering: Some project sites are dusty and prone to false alarms. You can add this to your receiving logic"Delayed confirmation": For example, only after receiving 3 consecutive alarms (with an interval of 2 seconds), it will be judged as a real fire alarm to avoid frequent power outages that affect the customer experience.

Summarize

The biggest advantage of Thingboot is thatAbstract complex IoT hardware into a few simple HTTP requests.

You don't need to know anything about embedded development or radio protocols. All you need is:

  1. Buy equipment and connect to the Internet;

  2. According to the document, writePOSTask;

  3. In your business logic, connect "smoke alarm" and "power outage/close door/send text message".

Whether you are developing a security system for your own warehouse or providing high-end building energy-saving solutions to customers, this setIntelligent remote monitoring smoke detector + universal controllerThe combination of punches can basically cover 90% of the needs of safety and energy-saving scenarios.

Hurry up and apply for an AppId to try it out. If you are quick, you will be able to get through the first "remote silence" function this afternoon.