is it possible that something is wrong with web installer…
its preparing installation …forever
It was working fine here when I tried before, but now I am actually seeing why you don’t get any decoded messages at all, with this and the previous test version. I should have seen it above already in the MQTT Explorer screenshot.
You are uploading, and previously uploaded, the -undecoded binary.
This will never decode anything, as the name implies, so you will always only see the raw servicedata, servicedatauuid and manufacturerdata.
Try with the esp32dev-ble binary. If this also still has upload issues for you, you can try erasing the flash separately at
https://espressif.github.io/esptool-js/
first, and then try the upload page again.
erase works
but still …preparing installation … and nothing
I also tried with another computer and different browser and different esp board
still preparing installation … and nothing
Hmm, just uploaded fine here.
Which OS are you using, which driver are you choosing when the upload begins?
A restart of the web browser or the actual PC might solve the issue, and/or alternatively briefly pressing the Boot/Reset buttons on your ESP32 when the upload is just about to begin.
Pressing boot at upload solved upload problem tnx.
i am testing sensors now
data is coming now in two packets with mqtt explorer
- id, name ,rssi packets are coming every minute
- sensor data packets are coming every 3 minute or so ,
but sensor values do not change very often with mqtt , values are changing about every 40 minutes or so
but with sensor native app “smart life” values are changing about every 3 seconds.
could it be that the sensors are bluetooth5 but the esp32 i am using openmqtt is bt4.
for app i am using phone huawei p30lite, it has also bluetooth 4.
What ESP chip is best for openmqtt?
{
“id”: “DC:23:4D:E4:16:0A”,
“name”: “TY”,
“rssi”: -44
}
{
“id”: “DC:23:4D:E4:16:0A”,
“name”: “TY”,
“rssi”: -45,
“brand”: “Xiaomi/VegTrug”,
“model”: “MiFlora”,
“model_id”: “HHCCJCY10”,
“tempc”: 19.8,
“tempf”: 67.64,
“moi”: 12,
“lux”: 662,
“fer”: 547,
“batt”: 100
}
{
“id”: “DC:23:4D:E4:16:0A”,
“name”: “TY”,
“rssi”: -65,
“brand”: “Xiaomi/VegTrug”,
“model”: “MiFlora”,
“model_id”: “HHCCJCY10”,
“tempc”: 19.8,
“tempf”: 67.64,
“moi”: 12,
“lux”: 662,
“fer”: 547,
“batt”: 100
}
{
“id”: “DC:23:4D:E4:16:0A”,
“name”: “TY”,
“rssi”: -81,
“brand”: “Xiaomi/VegTrug”,
“model”: “MiFlora”,
“model_id”: “HHCCJCY10”,
“tempc”: 19.8,
“tempf”: 67.64,
“moi”: 12,
“lux”: 662,
“fer”: 547,
“batt”: 100
}
Only the packets with 18 character length servicedata, like “servicedata”: “6000d2000224640000”, are being decoded, with the other previously quoted messages above likely being encrypted messages. This happens similarly to what you mentioned before as HA also only decodes the data every few minutes, as it uses the same decodable unencrypted data.
How often the data actually changes solely depends on the data being sent out by the device in its packages, now that the decoder is in place.
The app itself likely uses a connection to the device, registering for notifications at a more frequent rate.
Bluetooth 4 and 5 does not make any difference in the packets received which are being decoded, so you are fine with the ESP32 you are currently using.
If you really want to see how frequesntly the devices sends out messages with decodable data you could set
“interval”:100
“intervalacts”:100
“scanduration”:1000
and see how often decoded messages are being receved then. Make a note of the previous values, so you can set them back again afterwards, or possibly to values in between.
Some devices also behave differently depending on if they are connected/provisioned/paired with a native app or not, so that might be something to try out and test with this specific device, if you think you require more frequent updates. Other versions (green, white and black) of the HHCCJCY10 likely behave slightly differently with their data broadcasts.
Is this tuya pink version sensor support now included in openmqtt firmware?
It was included in the test firmware you installed and tried out above, but a new version of Theengs Decoder will be released soon, which, in turn, will then be included in the next release version of OpenMQTTGateway.
It will also be included in the nightly development builds of OMG from tomorrow onwards.