Power update via MQTT is not working as expected #17751
Comments
|
What I'm doing is to issue an extra |
|
This issue has been automatically marked as stale because it hasn't any activity in last few weeks. It will be closed if no further activity occurs. Thank you for your contributions. |
github-actions
bot
added
the
stale
Could you take it a bit further? I am not sure if I understood correctly. You mean you type |
|
While I could type it into the console, doing it manually is very impractical. I created a small bot publishing the command after a short delay (3 seconds, I think). That causes Tasmota to generate a payload with the same data as found in the telemetry SENSOR payload. Note that this depends on my automation taking this extra payload into account. |
github-actions
bot
removed
the
stale
|
Out of curiosity @Civlo85 : |
|
Yes I do. I see the correct value (or at least one that makes sense) on the web ui. And I also see it in the console.Does anybody know where this MQTT handling can be found in the source code? I am not so deep into this structure, could not find it directly.Von meinem iPhone gesendetAm 01.03.2023 um 21:46 schrieb AleXSR700 ***@***.***>:
Out of curiosity @Civlo85 :
When the boiler turns on, do you see the correct value on the Tasmota main web ui page?
And if you set weblog 4, do you see it in console as non broadcasted value?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
If you see values that makes sense in the console as in the SENSOR message then that is exactly what is published on mqtt. |
github-actions
bot
added
the
stale
|
This issue was automatically closed because of being stale. Feel free to open a new one if you still experience this problem. |
|
Hi @Civlo85, have you found a solution? I have the same problem and I'm not a fan of creating a bot that forces more mqtt messages just to get around a bug. In the last message you can see that it sent "Power: 15" when it should have sent "Power: 37". The web interface also showed 37. `16:55:50.462 MQT: tele/tasmota_A1T_1/SENSOR = {"Time":"2023-04-28T16:55:50","ENERGY":{"TotalStartTime":"2023-04-28T15:46:08","Total":0.017,"Yesterday":0.000,"Today":0.017,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.039}} 16:55:52.436 MQT: tele/tasmota_A1T_1/MARGINS = {"MARGINS":{"PowerDelta":-1}} 16:55:52.446 MQT: tele/tasmota_A1T_1/SENSOR = {"Time":"2023-04-28T16:55:52","ENERGY":{"TotalStartTime":"2023-04-28T15:46:08","Total":0.017,"Yesterday":0.000,"Today":0.017,"Power":1,"ApparentPower":7,"ReactivePower":7,"Factor":0.12,"Voltage":230,"Current":0.030}} 16:55:53.464 MQT: tele/tasmota_A1T_1/MARGINS = {"MARGINS":{"PowerDelta":7}} 16:55:53.474 MQT: tele/tasmota_A1T_1/SENSOR = {"Time":"2023-04-28T16:55:53","ENERGY":{"TotalStartTime":"2023-04-28T15:46:08","Total":0.017,"Yesterday":0.000,"Today":0.017,"Power":7,"ApparentPower":7,"ReactivePower":0,"Factor":1.00,"Voltage":230,"Current":0.030}} 16:55:55.466 MQT: tele/tasmota_A1T_1/MARGINS = {"MARGINS":{"PowerDelta":30}} 16:55:55.475 MQT: tele/tasmota_A1T_1/SENSOR = {"Time":"2023-04-28T16:55:55","ENERGY":{"TotalStartTime":"2023-04-28T15:46:08","Total":0.017,"Yesterday":0.000,"Today":0.017,"Power":15,"ApparentPower":15,"ReactivePower":0,"Factor":1.00,"Voltage":230,"Current":0.064}}` |
|
Hi @Boerny41 unfortunately I have no solution for my Tasmota devices. I tried to figure out what section of the source code is responsible for that, but I had no luck. To be honest, I thought there would be more help or at least good hints. My solution for now is to use completely different devices without Tasmota. |
|
I thought about returning mine because they make a high-pitched noise when turned off, but I couldn't find a non-Tasmota one that didn't require a cloud connection. Which one did you choose? |
|
I have encountered the same issue. I am joining the search for a solution. The actual power value is very important in my automation. |
|
The issue is as designed. What @sfromis already tried to explain is that the powerdelta signals a user configurable change. The reported values are measured in the process of the change. They are not the end result of the change. You need to know how energy measurements work. They are time based! Energy usage is calculated over a known amount of time. PowerDelta measures energy change every second. If the change is larger then the user configured threshold it reports the change. The final energy value is most probably different from the reported PowerDelta value. If you want to know the final energy level you will need to read the value once the transistion is complete. That's where a (rule) call to |
|
Okay, if it's a feature that sometimes the wrong number, a different number to the one shown in the UI, is send out, then I'd say it's a pretty bad feature because it only "works" 30% of the time. We could spend all day discussing whether sending the correct power value is a good thing for a power meter to do, but the fact is that sometimes it does and sometimes it doesn't. No matter how you look at it, there is an error. Since I believe that a power meter should report the correct amount, and since you don't seem interested in fixing it or even acknowledging it, I'm returning my units. Thank you for absolutely nothing. |
|
The number is not "wrong" or "incorrect", it is already sending the correct value. However, you must realize that what you see in the JSON is only relevant to the specific time stamp included in the JSON, and does not represent what the value would be a few seconds later, if the difference does not trigger another reporting. You could either use a lower PowerDelta value, or use my method of polling for an extra reporting. |
|
@sfromis The output I posted above essentially shows this: Power: 7 at 16:55:53.474 and there it stopped updating because a stable power consumption was reached. So far so good, the only problem is that the actual power consumption was ~37 watts, but the last message it sent out said 15 watts. You guys keep saying that this is how it's supposed to be (which I personally disagree with, but that's another topic), but then explain to me why it only behaves like this sometimes? Like 20 or 30% of the time. If it is intended, it should behave this way all the time. |
|
The last message you posted should not have been 37, but you cut the log so tightly, that it does not show what came next, and you gave no info about whether the consumption level change was gradual, or it was a step change. PowerDelta is from one measurement to the next, meaning that it will not react to a difference to 5 seconds ago, only to previous second. (101 means 1 watt, not 1%) |
|
The thing is, I didn't cut it tight, that's all. It stopped right there. No more messages. I'll do it again and now write down step by step what I did and also copy everything form the consol: I understand that it shouldn't update if the PowerDelta doesn't change, so it was right that there weren't any more messages after the last one, but as the last message said Power:12, which straight up wasn't true. That's also what Home Assistant will now show until the charge rate changes from 40 to something else that triggers an update. 19:06:19.438 MQT: stat/tasmota_A1T_3/POWER = ON |
|
I'll add my logs. The difference between the actual Power value and the value in the SENSOR topic is 1775 - 75 = 1700. The correct value in the SENSOR topic will be received on schedule. All this time my automation will run with the wrong value of 75, although the actual value is 1700. |
|
So, I think I found a solution by using rules without STATUS 8. |
|
Problem is that these kinds of workaround only work for stable power consumption. A lot of devices, especially electronics, fluctuate quite a lot. So the use case is very limited. |
|
Adding my logs. Running a keurig through a Sonoff S31. |
|
The issue isn't consistent. Using the workaround by @aliasnameless; |
|
Gents, you might want to dig in deeper and enable For CSE7766 you might see a serial datagram every 100mS. See the driver how to decode it. The above shown report tries to explain where the change in powerdelta power and reported activepower comes from. It's debateble if instead of changing active power based on measured current the current should be changed on measured active power..... Anyway, the current solution of using a rule to delay display of final results seems to be a working solution. |
Energy power delta report delayed by two seconds allowing hardware to stabilize (#17751)
|
Still trying to capture, but that makes sense if device reported U-I doesn't match device reported Power. |
|
What would the use case / value be of having PowerDelta depend on ApparentPower instead? With ActivePower being what is consumed, and what you're usually also being charged for (assuming normal household usage), this is the "natural" thing to focus on, and what Tasmota reports and summarizes, when calculating Energy Today, Yesterday and Total. |
|
Using PowerDelta as it is here for a mqtt publish is inappropriate because it's detecting a change to a value that's not even being sent/published. This causes data of interest to potentially not be captured as in the posts above. Since the mqtt publish sends ApparentPower, it's natural for us to want to events based on the changes in that value. ApparentPowerDelta or CurrentDelta. Confirmed that current update is lagging behind. |
|
What do you mean by stating "because it's detecting a change to a value that's not even being sent/published" ? The JSON in what you copy/pasted very much contains |
|
That was forced with a teleperiod delay rule. See my message log on 2023-05-10. There was two minutes where Power / UI was 1300W+ and didn't get published. |
|
You are still not explaining what the point would be of using ApparentPower instead of the real power being used and already what is being reported. The log you now refer to instead shows "Today" being incremented with 34 watt over a period of 93 seconds, and that increment is based on "Power" (same as "Active Power" in the web UI). That would match a power draw of 1316 W over that interval, a number in the same ballpark as the MARGINS values also published. If you were expecting to see something similar in the "Power" field in the JSON, that is likely be due to this being a momentary value at the time of reporting, instead of something useful for a period of time. And as already discussed, a single momentary value is not really useful when the consumption level jumps up or down. Anyway, arendst just made a change to delay PowerDelta reporting by two seconds. This will likely improve chances of values coming only after sensor has stabilized after the step up/down of consumption. You might want to see how this works out for you. |
|
I can already tell it will work out in my case because current lags between 0-1s. From what @arendst detailed out PowerDelta is reacting to device reported Power, but ApparentPower maxes at device reported (Voltage * Current). Theoretically they are the same data, but practically they are not the same data. Given a event based option vs a 2 second delay waiting (hoping) for current to catch up, I'm suggesting it makes more sense in the long run to react to the desired value component being sent without such a delay. |
|
RE: "what the point would be of using ApparentPower instead of the real power being used and already what is being reported." Review: Then examine: Before this specific time, Power is changing, but ApparentPower is capped due to Current not changing. Thus the reported Power is not the Power value that initiated the event. With the pending change |
Aha, so that's why the Powerdelta configuration started acting weird when I updated from 12.5 to 13.0. I am using the Powerdelta 101 setting to have very fast and detailed power consumtion updates in home assistant and it was indeed not following the values that were seen on the tasmota page of the power meter. I now downgraded again to 12.5 and the updates are much faster again, but if I understand correctly these values are not always that accurate? |
PROBLEM DESCRIPTION
I want to send the actual Power consumption measured by my tasmota device via MQTT to my local broker. But it does not work as expected. I set up my "powerdelta" to 10 in order to get updates whenever my power consumption changes by 10%. That was the idea. When I look to the console output, I can see, that the trigger seems to work, but the value in the MQTT publish is wrong! It seems to be a little bit behind. How to solve this problem?
Please have a look at this console output:
I have attached my coffee machine to this device and want to measure the energy consumption of the boiler within the machine. Now the machine is pre-heated and just turns the boiler on and off to hold the temperature. We are in idle mode with an power soncumption of 6 Watts. Now lets look at the logs:
We see, that the "PowerDelta" seems to trigger. It detects an increase of 1164 Watts. So in total we should habe 1170 Watts. But when we look to the MQTT message, we see that a power consumption of only 42 Watts is transmitted! Why?
Ok, now lets wait until the boiler turns off again.
Here we see two messages. First, a PowerDelta of -435 Watts was detected. So we should have something like 735 Watts. Via MQTT the transmitted message has 727 Watts. So thats somehow in the range. OK, for me.
Then a delta of -721 Watts was detected. So we should be at 6 Watts again when we take the power value from the MQTT message. And that is exactly what we see in the message output. So fine with that.
Lets wait untile the boiler turns on again.
No we are looking at two triggers again. First one detects a delta of 1165 Watts. So we should be at 1171 Watts. But the message in MQTT transmitts only 16 Watts.
The second trigger detects -1166 Watts. So we should be at around 5 Watts. The message sends 6 Watts, so fine with that.
The error seems to be at the rising edge. The trigger detects that increase of power, but the value is not available in the MQTT message. Why that?
And that is what is being logged out of that. It does not reflect the truth and makes monitoring impossible.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255:Backlog Rule1; Rule2; Rule3:Status 0:weblogto 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Nothing special here. It is not working the whole time.
EXPECTED BEHAVIOUR
I expect that the right values are being send via MQTT
SCREENSHOTS
See my error description.
ADDITIONAL CONTEXT
I want to track the power consumption of my coffee machine ;-)
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: