search

rianadon / the-energy-detective-py

Unofficial library for reading from The Energy Detective power meters
0 stars 3 forks source link

API changes #8

Closed rianadon closed 2 years ago

rianadon commented 2 years ago

I'm moving methods out of the TED class and into the spyder/mtu classes.

reader.mtu_value(reader.mtus[2]).energy becomes reader.mtus[2].energy().

rianadon commented 2 years ago

@realumhelp I wanted to check with you on this one since it's changing quite a bit of the API & code.

realumhelp commented 2 years ago

I looked through all the changes and I like them. I think this simplifies the interface and makes it easier to use. My only comment would be you may have lost a little bit of information on the type of data energy() is returning. So you should check the MTU's type at some point before using the results from energy() to know if it is a NET/LOAD/GEN/STAND-ALONE. I honestly don't really know the true difference between NET and LOAD, I think it just has to do with whether or not GEN is added to the total or not. For a system total display you wouldn't want to grab a STAND-ALONE MTU into that total because it has already been added in the NET MTU for instance.

It is late so hopefully that makes sense, the data is there just need to make sure it is interrupted properly.

realumhelp commented 2 years ago

This maybe future talk but when considering advanced system types that involve solar and such. Would you think load() and generation() type functions would be added similar to what I kinda brute forced here:

https://github.com/rianadon/the-energy-detective-py/pull/10/commits/c7a1d78301d27132aa0169dfd65004b0033dc9aa#diff-08c3daa550455abff6339903458fe845721453258e8bd9773a6396c2d22e35ffR117-R133

That data is specific to TED6000 so you have a small deviation between the TED5000 system.

rianadon commented 2 years ago

The load() and generation() sound great. I'm going to hold off on merging this until you finish that PR, then I can rebase and add those methods.

I don't understand the NET/GEN types either. I do agree though on the energy type; the returned energy type needs to be more specific.

realumhelp commented 2 years ago

The load() and generation() sound great. I'm going to hold off on merging this until you finish that PR, then I can rebase and add those methods.

I don't understand the NET/GEN types either. I do agree though on the energy type; the returned energy type needs to be more specific.

My theory is only certain queries make sense for certain SystemTypes: SystemType.NET:

rianadon commented 2 years ago

I'm a bit confused. Why does SystemType LOAD type have GEN Query? Or is that supposed to be NET?

realumhelp commented 2 years ago

I'm a bit confused. Why does SystemType LOAD type have GEN Query? Or is that supposed to be NET?

Just a guess but when you step through the TED settings UI you can clearly see the 3 different system types. A non-solar normal system will be called NET, the only MTU types allowed are (NET and STAND-ALONE). A solar config that is bi-directional, meaning the solar feeds both the grid and your house for consumption, that is called NET-GEN and the only allowed MTU types are NET, GEN, and STAND-ALONE (no LOAD option). The last type (NET-LOAD) is your solar only directly feeds the grid, not an internal breaker, so your panel is only consumption. This type only allows LOAD, GEN, and STAND-ALONE (no NET option).

Allowed MTU types based on SystemTypes allowed in TED Config UI: SystemType.NET: ---NET ---STAND-ALONE SystemType.LOAD: ---LOAD ---GEN ---STAND-ALONE SystemLoad.GEN: ---NET Query ---GEN Query ---STAND-ALONE

realumhelp commented 2 years ago

Looks like the formatting on my table got jacked up let me try to retry it:

These are what I think are the valid queries for the various system types. SystemType.NET: ---NET Query SystemType.LOAD: ---LOAD Query ---GEN Query SystemLoad.GEN: ---NET Query ---GEN Query

realumhelp commented 2 years ago

So theory would conclude that these are the definitions of the queries based on SystemType:

SystemType.NET: ---NET Query - Sum of all MTUs (only positive no GEN allowed in this config) ---LOAD Query - Empty (Can verify with my current system) ---GEN Query - Empty (Can verify with my current system) SystemType.LOAD: ---NET Query - My guess is this would be empty? ---LOAD Query - Sum of all LOAD MTUs (does not subtract any GEN because that is directly feeding the grid) ---GEN Query - Sum of all GEN MTUs SystemLoad.GEN: ---NET Query - Sum of all MTUs including all GEN so possibly negative if production is higher than consumption ---LOAD Query - My guess is this would be empty? ---GEN Query - Sum of all GEN MTUs negative number.

Again this is just my guess as I can't test it for real. We would need to find someone who had such a setup and would be willing to run some queries.

rianadon commented 2 years ago

Mine is SystemType.NET. I think it might be best to hold off on implementing these and adding a note in the README in case someone with a different system type is looking to use the library.

rianadon commented 2 years ago

I simplified YieldType to now have only 3 possible values: NET, LOAD, and GEN (i.e. removing the MTU and SPYDER_GROUP types). Does it make sense that the spyder/mtu values would be of type NET?

realumhelp commented 2 years ago

Mine is SystemType.NET. I think it might be best to hold off on implementing these and adding a note in the README in case someone with a different system type is looking to use the library.

My SystemType is NET as well. I think it would be safe to implement at least NET and NET-GEN system types and kind of ignore the LOAD-GEN system type. This type of system to me would be commercial rather than residential, no one gets solar and not use the power generated. I would probably rename LOAD to Stand-Alone and I think everything else should fall into place. I would pull the queries for NET and for GEN, leaving the LOAD query alone for now until we figure out what it does.

I simplified YieldType to now have only 3 possible values: NET, LOAD, and GEN (i.e. removing the MTU and SPYDER_GROUP types). Does it make sense that the spyder/mtu values would be of type NET?

It seems like there are three levels of the TED system: Overall System Totals (combined MTU values), Individual MTUs, and Spyders. So totaling all Spyders will always be <= their parent MTU values, totaling the MTUs will always be <= the DashData total values (ignoring generation for simplicity).

I would say all Spyder values are Stand-Alone, they aren't used for any of the totaling values. An MTU will be part of the NET total calculation so calling it NET could make sense.

rianadon commented 2 years ago

I would probably rename LOAD to Stand-Alone and I think everything else should fall into place.

Do you mean for YieldType? We still have a STAND_ALONE field in MtuType.

I would pull the queries for NET and for GEN, leaving the LOAD query alone for now until we figure out what it does.

For me the query with D=0 (currently labeled net in my pr) is the only query that returns nonzero values. Did I mess that up and is the D=0 query supposed to be the LOAD query? Because otherwise removing D=0 would break things.

I would say all Spyder values are Stand-Alone, they aren't used for any of the totaling values. An MTU will be part of the NET total calculation so calling it NET could make sense.

Now that I think about it more, I don't think keeping around YieldType is useful, since Spyders and MTU don't fit in well with the load/gen/net/stand-alone definitions. Besides, for every method the YieldType is fixed, so you know if you call .energy() on a spyder you will get spyder/stand-alone energy, if you call .consumed() you will get load energy, if you call.energy() on an MTU you either get NET energy (if MTUType=NET) or stand-alone (if MTUType=Standalone), etc.

realumhelp commented 2 years ago

I agree it might be a stretch to keep YieldType since it only really make sense for the DashData queries. Any individual queries (ie:MTU/Spyder) it doesn't really mean anything if you remove the MTU and Spyder types.

DashData.xml Query 'D' params: D=0 is for NET D=1 is for LOAD D=2 is for Generation

If your system is a LOAD-GEN type I don't think we can support this without getting some system behavior. I have high confidence that if your system is NET-GEN then both the NET and the Generation queries on DashData.xml will behave as expect. That's what I was trying to get across.

realumhelp commented 2 years ago

My current guess is that if your system is LOAD-GEN then the DashData.xml NET queries will return all 0's and the LOAD queries will return the cumulative values.

realumhelp commented 2 years ago

You could probably boil the system down into two different types: NET + GEN and LOAD + GEN

If you only have one MTU you fall into the NET + GEN category but the GEN queries will always return 0.

rianadon commented 2 years ago

It sounds like without having a type besides NET for testing, it'll be difficult to correctly implement the other system types. For now I'm thinking we could check when retrieving net if the yield = EnergyYield(0, 0, 0), and if so return the load so that we can always send the net value to Home Assistant and if the system type has + GEN then return net as well as gen?

realumhelp commented 2 years ago

I just factory reset my system for science to try and see what this LOAD business is!

Test #1 - Setup LOAD-GEN using my normal MTU as a LOAD, fake MTU as GEN:

Test #2 - Setup LOAD-GEN using my normal MTU as a GEN, fake MTU as LOAD:

Test #3 - Setup NET-GEN using my normal MTU as a NET, fake MTU as GEN:

So mind boggled but those are the results.

realumhelp commented 2 years ago

I ran Test 2 again because the results looked weird (MTU1 is fake and MTU2 is real):

<Configuration>
  <SystemType>2</SystemType>
  <MTUType1>1</MTUType1>
  <MTUType2>2</MTUType2>
  <MTUType3>0</MTUType3>
  <MTUType4>0</MTUType4>
</Configuration>

api/DashData.xml?T=0&D=0&M=0

<DashData>
  <Now>2088</Now>
  <TDY>270</TDY>
  <MTD>270</MTD>
  <Avg>42480</Avg>
  <Proj>1316880</Proj>
  <Voltage>0</Voltage>
  <Phase>195</Phase>
</DashData>

api/DashData.xml?T=0&D=1&M=0

<DashData>
  <Now>0</Now>
  <TDY>0</TDY>
  <MTD>0</MTD>
  <Avg>0</Avg>
  <Proj>0</Proj>
  <Voltage>0</Voltage>
  <Phase>195</Phase>
</DashData>

api/DashData.xml?T=0&D=2&M=0

<DashData>
  <Now>2086</Now>
  <TDY>270</TDY>
  <MTD>270</MTD>
  <Avg>42480</Avg>
  <Proj>1316880</Proj>
  <Voltage>0</Voltage>
  <Phase>195</Phase>
</DashData>
rianadon commented 2 years ago

I just factory reset my system for science to try and see what this LOAD business is!

Wow. Thank you for doing this! I admire the dedication.

As for GEN being positive, I think this might be the solution (from the installation manual)

image
realumhelp commented 2 years ago

Yea that is probably the issue. I'll see if I get some time to open my panel up and see about switching it. I'm not sure it will make much of a difference anyway since I'm not sure the impact the fake MTU had on things.

I think the original plan to check for NET == EnergyYield(0, 0, 0) is still a good path forward.

rianadon commented 2 years ago

I made a few changes:

I also noticed you used LOAD-GEN and NET-LOAD interchangeably. I think LOAD-GEN is the correct term to use, right?

rianadon commented 2 years ago

Also thank you again for your testing! I think I am finally understanding how the API works with your help.

realumhelp commented 2 years ago

Yep typo sorry. NET-LOAD doesn't exist it is LOAD-GEN. Even after all those tests I don't think I could 100% tell you exactly what NET/LOAD/GEN all mean. The interface isn't very self documenting via reverse engineering.

Just a note on setting the generation negative you might want to do the absolute value just in case the value itself if actually negative. You don't want to accidentally flip it positive because as you said in the TED instructions I may have to flip some wires around to get a negative reading.

rianadon commented 2 years ago

Just a note on setting the generation negative you might want to do the absolute value just in case the value itself if actually negative. You don't want to accidentally flip it positive because as you said in the TED instructions I may have to flip some wires around to get a negative reading.

The problem is that NET and/or LOAD will also depend on how the magnitude of GEN, so if GEN Is plugged in incorrectly then there will be more problems than just GEN being negative. So I think it's better to keep GEN negative if it's plugged in wrong so that it's easier to notice there's a problem.

rianadon commented 2 years ago

I edited the TED5000 _parse_mtu_type, as according to the documentation type zero is a LOAD:

image

This forum post says that Adj. Load is bi-directional, so is equivalent to NET.

I also implemented the TED5000 .consumption() method as summing up LOAD mtus and the .production() method as summing GEN mtus. I could also try to include the stand-alone and the net mtus depending on whether they are positive and negative, but this doesn't make sense for cases where the today's energy is positive but monthly energy is negative for example.

realumhelp commented 2 years ago

Good catch!

rianadon commented 2 years ago

I'm going to merge this one in. Thank you for all the reviewing!