Have you looked for this feature in other issues and in the docs?
yes, found no solution but hints for the problem
Is your feature request related to a problem? Please describe.
My electricity meter (EMH ED300 L) gives always positive values for D_TPWRCURR "Current-In/Out" but "Current Out" should give negative values
Describe the solution you'd like
In dependence of a hex value, which I maybe have to identify, there could be a negative value.
In my case I could identify the hex value which shows if the power is coming in or goes out.
Would be nice to be able to make values negative if the meter does measure outgoing power.
Is it possible to have a descriptor / variable to use for this issue?
Details see: https://forum.creationx.de/forum/index.php?thread/1095-d0-z%C3%A4hler-sml-auslesen-mit-tasmota/&postID=31606#post31606
Describe alternatives you've considered
Don't see an alternative because I do not have enough programming knowledge.
Additional context
This feature is necessary because graphs show false pictures an maybe I can do more logical controlling if I get the correct value vor In / Out Power
(Please, remember to close the issue when the problem has been addressed)
You posted in creationx forum where Gemu is active. He is the author of this driver.
Please ask there too for help.
@gemu2015 Can you take a look into?
You posted in creationx forum where Gemu is active. He is the author of this driver.
Please ask there too for help.
@gemu2015 Can you take a look into?
I had already tried to answer this question in the forum. However, the code would actually have to be adapted.
If I understood it correctly, it is about the fact that the consumption value has a different sign depending on whether energy is being consumed or fed in. So it is not about two different values where one value stands for the consumption and the other for the feed-in but a value that covers both.
@honikos I hope I have understood this correctly.
If I understood it correctly, it is about the fact that the consumption value has a different sign depending on whether energy is being consumed or fed in.
At the moment there is no distinction between consumption or feed-in. Per definition the value shows only the energy in W. But it makes sence to have a negative value when the meter measures feed-in (s. picture).
So it is not about two different values where one value stands for the consumption and the other for the feed-in but a value that covers both.
As mentioned above it is one value which could give more information as only track the actual energy. It ist possible to show the direction of energy flow ( - / negative if feed-in).
@kugelkopf123 don't know if understood .... hope it helps.

according to the data sheet this meter does NOT support negative values on current power!
This is not a fault of the sml decoder which of cause works with negative values if supported by the meter (e.g 2 way meter EHZ363)
Hi guys,
just found this issue and I am facing the same problem. The direction information is stored in the status part of the 108 and 208 messages. So if there is an easy way to parse the "A2" or "82" we can do the calculation on our own in the script.
77070100010800FF 640101 A2 01 621E 52FF 56 0001450FA101 --> Bezug
77070100010800FF 640101 82 01 621E 52FF 56 000145A40201 --> Einspeisung
Update:
I found the input for the statusword here on page 31 when I developed a first SML module for FHEM:
https://www.vde.com/resource/blob/951000/252eb3cdf1c7f6cdea10847be399da0d/fnn-lastenheft-edl-1-0-2010-01-13-data.pdf
Best regards
Matthias
thanks Matthias for the hint (energy direction in status)
ok silly meter why not returning a signed current power value?
However i did put the status into a script variable
enabled by
var=sml(mn 2) mn=meter number
returns the value in question (a2 or 82) as decimal
its on my fork, if tested i make a pr
files affected scripter and sml
Hi gemu,
great. Thanks! I will give a try and report back.
Matthias
Hi again,
used the lunchbreak to reflash the ESP and added your config. Hope I understood the structure correct:
Config
`>D
>B
=>sensor53 r
>M 2
+1,13,s,0,9600,SML
+2,4,c,0,50,Haus
1,77070100010800ff@1000,Verbrauch,KWh,Total_in,2
1,77070100020800ff@1000,Einspeisung,KWh,Total_out,2
1,770701000F0700FF@1,Aktuell,W,current,0
1,77070100000009ff@#,Meter Nr,,Meter_number,0
2,=h==================
2,77070100010800ff@1000,Total Verbrauch,KWh,Total_in,4
2,77070100010800ff@1000,Total Einspeisung,KWh,Total_out,4
>S
print %sml("797422-5001138" 2)%
#`
But as result I get only a 0.00 in the console. I also tried meter number 1, but the result stays the same. Do I have an error in my script?
12:35:41 MQT: tasmota/smartmeter/tele/SENSOR = {"Time":"2020-03-27T12:35:41","SML":{"Total_in":18480.81,"Total_out":32976.35,"current":4573,"Meter_number":"797422-5001138"},"Haus":{"Total_in":0.0000,"Total_out":0.0000}}
12:35:41 0.00
12:35:42 0.00
12:35:43 0.00
12:35:44 0.00
12:35:45 0.00
12:35:46 0.00
Looks like "Haus" is not your SML meter. Should be the first one.
So maybe false meter number ?
Nope, Haus can be ignored for now. I am waiting for a replacement of my second meter. I want to have it running for meter 1 (SML). That麓s the EDL300.
So I also tried print %sml(1 2)%. But this also does not work.
ok is this status only transmitted on 180 and 280 and not on the others?
then i have to decode this also, will update this afternoon.
Correct. Only 180 and 280.
Thanks!
next try !
Unfortunately I cannot compile it. And with my poor C knowledge I cannot spot the error.
Sonoff-Tasmota-universal8\tasmota\xsns_53_sml.ino: In function 'uint32_t SML_Status(uint32_t)':
xsns_53_sml:2082:10: error: 'sml_status' was not declared in this scope
return sml_status[meter];
did you type
in your user config overwrite ?
Oh man, I mixed it up with the EDL300. Now it worked. Sorry.
I get now a 162 in decimal in the console. So it seems to work. I will have another look in the afternoon when the sun goes away. Then I would expect a 130 in decimal (82 hex). Thank you very much!
Now I have to figure out how I can bring this value into the webinterface and calculate the value for MQTT, but this is well documented. I will post my solution here.
Update: Sun is gone and value changed to 130. So works like a charm.
Update2: This is now my script for adding a new value with correct +/- values. Maybe not perfect, but it does its job. Thanks again gemu2015 for the fast support!
>D
sml1state=0
currentwatt=0
>B
=>sensor53 r
>T
currentwatt=SML#current
if sml(1 2)==162
then
sml1state=-1
else
sml1state=1
endif
currentwatt=currentwatt*sml1state
>J
,"current:%currentwatt%
>W
==================
SML Aktuell +/- </th><td>%currentwatt% W</td>
>M 2
+1,13,s,0,9600,SML
+2,4,c,0,50,Haus
1,77070100010800ff@1000,Verbrauch,KWh,Total_in,2
1,77070100020800ff@1000,Einspeisung,KWh,Total_out,2
1,770701000F0700FF@1,Aktuell,W,current,0
1,77070100000009ff@#,Meter Nr,,Meter_number,0
2,=h==================
2,77070100010800ff@1000,Total Verbrauch,KWh,Total_in,4
2,77070100010800ff@1000,Total Einspeisung,KWh,Total_out,4
#
new version available
the new version directly inverts current power (770701000F0700FF ) on solar feed, so you should get negative values
so this stupid meter should be fixed!
Please be sure to review the code of conduct and be respectful of other users.
Keep in mind, this repository uses the Contributor Covenant.
@gemu2015
For me it doesn't work out of the box.
part of my user_config_override.h:
@matzefisi
Do I need all this stuff if I use #define ED300L ?
As @gemu2015 wrote, I would expect a negative output for line
1,770701000F0700FF@1,Aktuell,W,current,0
but I get a high value .... (think its without decimal ...)
@honikos Had you used the version from @gemu2015 fork?
Sent with GitHawk
@kugelkopf123 Yes I did.
try new version (bug removed)
ok, did it. Value looks good. Now waiting for the sun. Will give feedback when I have feed-in.
perfect. it works :-)
should be merged into the base branch. hope that there are other meters with same behavior. can maybe be solved by script.
@gemu2015 Thank you!

Most helpful comment
perfect. it works :-)
should be merged into the base branch. hope that there are other meters with same behavior. can maybe be solved by script.
@gemu2015 Thank you!