search

openshwprojects / OpenBK7231T_App

Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601, BL602 and LN882H
https://openbekeniot.github.io/webapp/devicesList.html
1.46k stars 273 forks source link

MQTT not responding as expected to 'get' #1093

Open TurkeyMan opened 8 months ago

TurkeyMan commented 8 months ago

Describe the bug MQTT not responding as expected to a 'get' with no payload (request to publish value immediately). The device samples and reports the energy meter data at a very low frequency. When I change the energy usage, like turning on a light, it can take quite a while before it decides to publish an updated value. I want to increase the update frequency of some values, so my plan is to poll them at the desired rate, however it doesn't respond as expected...

Firmware:

To Reproduce Steps to reproduce the behavior: PUBLISH device/0/get with no payload and device responds device/0/get = true as expected; it reports channel 0 correctly. PUBLISH device/voltage/get with no payload and device responds device/0/get = true, which is incorrect! I didn't request channel 0, I requested the voltage value, but it responds with channel 0 instead for some reason.

Log:

Info: MQTT - Sent PUBLISH to obk125DAED5: 1, obk125DAED5/voltage/get =  (qos: 0)
Info: MQTT - Received PUBLISH from obk125DAED5: 6, obk125DAED5/0/get = 0 (qos: 2)
Info: MQTT - Sent PUBREC to obk125DAED5: 6
Info: MQTT - Received PUBREL from obk125DAED5: 6
Info: MQTT - Sent PUBCOMP to obk125DAED5: 6
TurkeyMan commented 8 months ago

I worked out how to make it emit tele/obk125DAED5/SENSOR reports, which I can parse, but it's not ideal. Also, it just seems to make those tele reports in its own good time... can I control the frequency of those reports? I want reports at much higher frequency. I tried publishing tele/obk125DAED5/SENSOR with no payload to request an immediate report, but that didn't do anything.

openshwprojects commented 8 months ago

I think you can use VCPPublishIntervals and VCPPublishThreshold and VCPPrecision. The voltage (etc) is not linked to get currently

TurkeyMan commented 8 months ago

Maybe MQTT isn't the best protocol for realtime monitoring... my other modbus-based devices poll at ~20hz (report every 50ms), and I consider that slow (limited by RS232 at 9600bps). It'd be much more useful to have a connection to these devices with an active data stream which just pushed data the instant it samples it, at the same frequency that it samples. These devices are a data-source; we need to access the raw realtime data, and allow out applications to determine how to process/smooth it out. MQTT can do this, but it's a noisy protocol.

Without changing the behaviour of these devices as they are, I'd really like a feature for realtime usage. To achieve this within MQTT, here's what I think might work well:

  1. Since MQTT can only include a single topic/value in a PUBLISH message, we should create a topic for realtime message aggregation; ie, DEVICE/realtime
  2. Device should PUBLISH to DEVICE/realtime immediately for every hardware sample in realtime (or some otherwise high rate including recent raw samples), include in the message all topic+value pairs that changed since the last report, and most importantly; publish with QoS=0 to eliminate all the ACK chatter.
  3. Configuration for the devices internal sampling frequency, for some fields (ie, current + power) I want to sample at the highest possible frequency.

I reckon this could be implemented while leaving all other implementation details as they are, just an additional option to enable DEVICE/realtime reporting.

For interest's sake; the reason I want this, is because I'm writing monitoring software which can identify and isolate individual devices present on a circuit by identifying their signatures during operation. To build these signature profiles, I need high resolution raw data, otherwise the signatures are very poor. This allows pseudo-monitoring of individual devices connected to power outlets with just a single meter on the circuit. These devices are realtime raw data sources; the software running on the device itself shouldn't limit the way it's used. The data needs to be accessible at the highest resolution that the device can record.

TurkeyMan commented 8 months ago

I think you can use VCPPublishIntervals and VCPPublishThreshold and VCPPrecision. The voltage (etc) is not linked to get currently

Can you point me at documentation to tinker with these values? I can fiddle with this, but I reckon that's probably not sufficient. What I just wrote above seems like a proper path forwards.

TurkeyMan commented 8 months ago

Actually, sorry, this isn't fixed.