output in json format

[G0sch]

Hi,

I like the script very much, but is it a big deal to get the output in json format?
(e.g using it in Node Red flow)

thx
G0sch

[JsBergbau]

Hi G0sch
Since the script outputs a lot of status messages, it would need relatively much time to change it to output only JSON. I suggest using a callback script to generate JSON output.
You can also use the MQTT callback and use MQTT in Node-RED to work with the values.

Do you use a influxdb? I use the data in NodeRED as well. However every script writes it directly to influx DB and then Node RED fetches the results.

[G0sch]

Thank you for your fast reply. I will check the callback option

[JsBergbau]

Hi @G0sch
I'm considering creating a Node Red node for LYWSD03MMC sensor with ATC firmware. So stay tuned.

[JsBergbau]

Hi @G0sch
new version is out with callback to send to Node-RED. There are also flows provided for easily usage of the data in Node-RED.

[G0sch]

cool - thank you. will test it. you wrote you will create an node-red node... is it still on the roadmap?

[JsBergbau]

I've created a flow (MiTemperature2 Node-Red Flows.txt) with which you can also use the script. The flow / possibilities with this solution is quite complex, there are so many possibilities. Would be hart to pack that into a single node while keeping it clear.

Just tell me after testing/trying out if you still see many advantages in an own node. Then I would take your input into the Node design. However it could take a while, because currently I have so many other fascinating projects.

[G0sch]

yes will test it in the next days! thx

[JsBergbau]

Hi @G0sch,

Hope the provided solution satisfies your requirements. I've also taken just a brief look into doing with creating a native Node-RED Node. It would be possible, however it has a major disadvantage: The noble library doesn't support passive scanning right now, see abandonware/noble#151
So it would do an active scanning. Active scanning means that there is an request that queries the device, especilly for its name. So with each received advertisment there is a request made to the Temperature sensor and it sends data like it's name back. Thus leads to higher battery usage. And I guess since the bluetooth device has to transmit data it takes longer to scan all three advertisment channels and while transmitting the query it cant receive. So the likely hood of not getting an advertisment increases.
Even though my sensors change advertisment data every 10 seconds, I only get a stable new measurement storing it in chunks of 25 seconds. Even storing the new value in chunks of every 20 seconds leads a few times per hour to no new value.

When you start the script in ATC mode you can see that scanning is passive via hcidump

sudo hcidump
HCI sniffer - Bluetooth packet analyzer ver 5.50
device: hci0 snap_len: 1500 filter: 0xffffffff
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
    type 0x00 (passive)
    interval 1280.000ms window 1280.000ms
    own address: 0x00 (Public) policy: All
> HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
    value 0x01 (scanning enabled)
    filter duplicates 0x00 (disabled)
> HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00

[G0sch]

Hi @JsBergbau

first: thank you for the great support and effort :-)
I tested the flow, but imho it much more complex like an native node.

What I do to simplify it for my need:

1. I reduced the output of your script to "temp, bat%"
2. another node converts it to json (msg.payload.split(","))
3. input node delivers the MAC and room as msg.topic (using it for floor heater) every 3 minutes

here the options: LYWSD03MMC.py --unreachable-count 5 -c 1 -r -deb -b --device

I also understand the point with noble - so I still think the smartes way is to get json output directly from your script... :-)

[JsBergbau]

I tested the flow, but imho it much more complex like an native node.

True. The sample flow is for ATC version where you can have multiple receivers and then this complexity makes sense. For your solution connecting to a single sensor it doesn't need that complexity.

Changing the script to json output is not that simple, because for example the callback sending thread may also print to stdout. It would be a lot of effort to really make it print only valid json and needs a lot of tests to ensure that for every case. So I wouldn't it consider the smartes way.

[G0sch]

finally the workflow will monitor 6 sensors/rooms - may be I will tune the flow a bit for this.
But understand your point

[JsBergbau]

As you wrote you take the temperature to control heater:
Take a look at this firmware https://github.com/atc1441/ATC_MiThermometer to get much more stability.
With this firmware data is transported als BLE advertisment. With this the battery usage is very low.
With the solution where you connect it happens on low signal strength that battery is empty after 1-2 month. There is no possibility to check this. Take a look at this #32

Another problem: If battery of one device gets empty it can stop whole raspberry pi from receiving other sensors. I don't know what exactly happens. I had this situation a few times and then at least one battery is empty. You see that because sensor reboots while connecting. Connecting needs a lot of power, battery voltage drops a lot --> reboot.
You have then to reboot Raspberry Pi, I've found no other soultion getting it back to work.
Perhaps this problem is unrelated to battery but with empty battery sensors constantly reboot and thus leading to a high number of new connections and perhaps that causes bluetooth failing.

[G0sch]

I'm testing the ATC firmware an two sensors for now - with 1 or 5 min interval.

Thx for the battery empty hint - will implement an alerting to prevent it!