Installed pvvx 4.6;
which parameters do you recommend?
Thx
For now, results are the same:
very frequent and precise results with Tasmota
unfortunately not the case with OMG:
Let me know if you have suggestions to troubleshoot the issue, thx.
Thanks for the data, are the 2 esp32 located at the same distance from the sensor?
With an advertising interval of thePVVX firmware of 2.5 seconds, and
"interval": 1000,
and
"scanduration": 1000,
you could well miss the broadcast several time, with it falling into the interval reception pause.
How about setting
"scanduration": 3000,
so that each scan should pick up at least a single broadcast from the LYWSD03MMC.
1 Like
Thanks for the feedback,
In fact the OMG ESP32 is actually closer to the device than the Tasmota ESP32.
I had already set “scanduration” to 5000 earlier today after upgrading to pvvx4.6 but still no success:
I also tried to disable the Tasmota ESP32 in case there was some kind of conflict but it has no effect on the OMG response frequency. something else is going on on the OMG side.
Did you not set/change the minimum rssi to quite a bit lower earlier on?
"minrssi":-70
so that your OneMQTTGateway is much less sensitive to publishing picked up devices.
How about setting it back to the default -100.
I was back to -92 but changed to -100 just to be sure. Still no change.
This sensor is used to trigger the shower fan so I do need frequent refresh. I can use Tasmota but puzzled at why results are so different.
Could you erase your flash and try a stock v1.7.0 esp32dev-ble firmware if not already done?
Would be interesting to see the behaviour with the default parameters.
Not possible OTA unfortunately.
Although I’m not sure if an erase and then init of the saved settings in flash would function in a similar way with a pre-build binary install, but really best to to a complete erase flash via cable 
ESP32 erased + fresh install/flash. A little better but still not great.
Tried not to use round numbers to avoid some type of command overlapping.
Is there some type of data “filter” as it seems the data resolution is low.
Last option would be to change the ESP32 unit itself. Maybe some physical issue with the BLE receiver? but even then, for the same device, OMG reports RSSI -70 and Tasmota -85…
{
"bleconnect": true,
"interval": 5555,
"adaptivescan": true,
"intervalacts": 1212,
"intervalcnct": 9595,
"scanduration": 9393,
"onlysensors": false,
"randommacs": false,
"hasspresence": false,
"prestopic": "presence/",
"presuseuuid": false,
"minrssi": -100,
"extDecoderEnable": false,
"extDecoderTopic": "undecoded",
"filterConnectable": false,
"pubadvdata": false,
"pubuuid4topic": true,
"ignoreWBlist": true,
"presenceawaytimer": 120000,
"movingtimer": 60000,
"forcepscn": false,
"tskstck": 2592,
"crstck": 1556,
"enabled": true,
"scnct": 569
"scnct": 576
}
Ok, looking better already, but not quite what you’re expecting.
Could you do a few more adjustments to your setting?
Initially, can you set
"bleconnect": false,
"adaptivescan": false,
As the LYWSD03MMC do not require active scanning you can set
"intervalacts": 300000,
just for testing to only scan actively every 5 minutres - I don’t know what other sensors you might have which require active scanning.
Then for a more frequent passive scanning you can keep
"interval": 1000,
but set
"scanduration": 5000,
This should give you a reading every 6 seconds.
Could you also monitor the LYWSD03MMC in MQTT Explorer History for the device. Just to see if there are possibly some undecoded messages in between the decoded ones, in a format which we do not currently decode. What are the reading intervals in parenthesis in the History?
Other than that I am also not sure of some of the PVVX settings you showed above when installing it. Were those the default suggested settings?
Thanks. you didn’t specify intervalcnct so I’ve used 1500.
Will monitor both HA and MQTTexporer.
more to come.
"bleconnect": true,
"interval": 1000,
"adaptivescan": true,
"intervalacts": 300000,
"intervalcnct": 1500,
"scanduration": 5000,
"onlysensors": false,
"randommacs": false,
"hasspresence": false,
"prestopic": "presence/",
"presuseuuid": false,
"minrssi": -100,
"extDecoderEnable": false,
"extDecoderTopic": "undecoded",
"filterConnectable": false,
"pubadvdata": false,
"pubuuid4topic": true,
"ignoreWBlist": true,
"presenceawaytimer": 120000,
"movingtimer": 60000,
"forcepscn": false,
"tskstck": 3948,
"crstck": 3056,
"enabled": true,
"scnct": 3
Intervalcnt should be every hour at maximum if you have devices eligible to connection.
I would better set it to 3600000
Done.
Intervalcnt set to 3600000
Doesn’t look too bad.
I think the extra resolution on the tasmota side comes from the fact that I have a secondary esp32 outdoors which probably feeds additional data from the same sensor.
Can I do the same with OMG, IE: have multiple ESP32 publish to the same topic?
Yes of course. It works by default like this.
That’s what I thought originally but this is what I’m getting once I rename the gateway/topic as per my other esp32 (OMG_BLE1/OMG_BLE1):
Once I rename it back to OMG_BLE2/OMG_BLE2 all is good.
The logic that we use to have in the controllers for this, is to have them subscribe to +/+/112233445566 , 112233445566 being the sensor id.
This way you can respect the MQTT topic structure and easily identify your gateways.
Currently the gateway name is used as the client id, so having a duplicated cliebt id is not mqtt compliant and generate the disconnections.
I may change this to take the mac as the client id.
So if I get this right, with the current payload structure
it is not possible to publish to the same topic with multiple esp32 unless you change clientid to mac address / future release?
Edit: guess I could manually create a sensor with the +/+/112233445566 structure…
