ngardiner / twcmanager Goto Github PK

refresh.png is not a png. It looks like html text.

Sending the Stop command (which triggers a hard stop via the contactor being de-energised) results in a confirmation message being sent by Slave TWCs in the following format:

UNKNOWN MESSAGE FROM SLAVE:FD B2 NN NN 00 00 00 00 00 00 00 00 00 00 00 5A

NN NN denotes the Slave TWC's TWC ID. We should trap this message within the protocol parser to avoid reporting an unknown message when the Stop command is used.

Similar to #40, the output of update_statuses() is really only correct / relevant when tracking green energy. Perhaps a different message should be shown less frequently when other policies apply?

(Note, several of these minor issues are as much notes to myself of things to get to later as requests for you. Please don't mind picky items. 🙂)

On providing a username and password the following error is logged when the login button is clicked:

----------------------------------------
Exception happened during processing of request from ('x.x.x.x', yyyyy)
Traceback (most recent call last):
  File "/usr/lib/python3.7/socketserver.py", line 650, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python3.7/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.7/socketserver.py", line 720, in __init__
    self.handle()
  File "/usr/lib/python3.7/http/server.py", line 426, in handle
    self.handle_one_request()
  File "/usr/lib/python3.7/http/server.py", line 414, in handle_one_request
    method()
  File "/home/pi/TWCManager/lib/TWCManager/Control/HTTPControl.py", line 302, in do_POST
    self.process_teslalogin()
  File "/home/pi/TWCManager/lib/TWCManager/Control/HTTPControl.py", line 343, in process_teslalogin
    carapi = self.master.getModuleByName("TeslaAPI")
AttributeError: 'HTTPControlHandler' object has no attribute 'master'
----------------------------------------

The browser displays:

Running v1.1.8

Currently, we ship a Makefile that does a half-install (it copies the main TWCManager.pl script to /usr/bin but does no more than this). This adds no value as the libraries on which the script is dependent are neither installed, nor located in an inbuilt search path.

This is a good opportunity to investigate a proper setup mechanism using setuptools, for example. Ultimately we could build a package ready distribution rather than having to install from source.

Currently, I have a home automation rule that monitors the Powerwall load, and if the load becomes excessive (7.5kW) without corresponding solar, it switches to grid power instead of battery power to avoid needlessly draining one battery into another. Right now, it checks every five minutes; that's fine for detecting when to go back to battery power. However, I'd like to have it switch immediately when charging starts. When the automation triggers the charging, that's easy; when it's just acting based on policy, less-so.

We already have actions (check arrival, scheduling of check departure) that fire when charging starts/stops. It would be nice to be able to provide a web hook, a URL that gets notified when charging begins and when it ends; for my setup, I really only care about these on non-green policies, but one reasonable way to do this would be a property on the policy that gets notified when charging begins. Notification on charging end would be easy to add in the same way.

The obvious way to build this is simply a property on custom policies and an ability to add them for the built-in policies in config.json. However, we have so many things like that, I'm almost wondering if there should be a more uniform way to specify property additions to built-in policies. (Of course, since we already cut a version containing several of those, the more important concern might be not breaking those.)

Any thoughts on how you'd like to see this structured?

Thanks to @dschuesae's PR we have picked up a regression with the new policy structure: It removes a feature from the past where setting nonScheduledAmpsMax to -1 would result in green energy tracking instead of non-scheduled amps.

I'd like to fix this a number of ways:

1. Remove the old option from the old webui to avoid confusion. Even when we do fix this, I wouldn't want to do it with a negative amps max value - the reason we've avoided this in the new policy code is because it could easily slip through the cracks and cause some weird behaviour if it was indeed taken as the charge amps value.

2. Add an option to the new webui to allow this. It would be a new boolean value in the settings.json file and could then be set as a policy condition.

3. Add a catch-all track green energy policy rule after non-scheduled charging so that if this boolean sets the behaviour to skip non-scheduled charging, it will track green energy instead.

I keep having to restart TWCManager in order to have live information on the Web interface, although I suspect that the stale web interface is a side effect of something core stopping running or getting blocked.

I currently have TWCManager in a failed state so if there are any fault finding steps I can carry out happy to investigate.

From the logs I can see that logs from category TWCManager have stopped, as have logs from TeslaVehic, but other logs are continuing to be generated. These logs were generated every 60 seconds and then stop, at around the time they stop this error is generated:

May 20 22:01:01 twc python[19637]: 22:01:01 HASSStatus 4 Error connecting to HomeAssistant to publish sensor values

However that was not the first time that error is logged, so I'm not convinced it's related. Full section of log from when the TWCManager log stops:

May 20 22:00:23 twc python[19637]: 22:00:23 TWCManager 1 Limiting charging to 0.00A.
May 20 22:00:23 twc python[19637]: 22:00:23 TWCManager 1 Charge when above 5A (minAmpsPerTWC).
May 20 22:00:23 twc python[19637]: 22:00:23 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_config_min_amps_per_twc (value 5).
May 20 22:00:24 twc python[19637]: 22:00:24 TeslaAPI   8 Entering car_api_available - next step is to query Tesla API
May 20 22:00:24 twc python[19637]: 22:00:24 TeslaAPI   8 car_api_available returning True
May 20 22:00:49 twc python[19637]: 22:00:49 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_amps_max (value 0.0).
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     8 Evaluating Policy match (settings.chargeNowAmps), condition (gt), value (0), iteration (<built-in function iter>)
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     8 Policy conditions were not matched.
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     8 Evaluating Policy match (checkScheduledCharging()), condition (eq), value (1), iteration (<built-in function iter>)
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     8 Policy conditions were not matched.
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     8 Evaluating Policy match (tm_hour), condition (gte), value (6), iteration (<built-in function iter>)
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     8 Evaluating Policy match (tm_hour), condition (lt), value (20), iteration (<built-in function iter>)
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     8 Policy conditions were not matched.
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     8 Evaluating Policy match (none), condition (none), value (0), iteration (<built-in function iter>)
May 20 22:00:53 twc python[19637]: 22:00:53 Policy     7 All policy conditions have matched. Policy chosen is Non Scheduled Charging
May 20 22:00:53 twc python[19637]: 22:00:53 TWCManager 1 Limiting charging to 0.00A.
May 20 22:00:53 twc python[19637]: 22:00:53 TWCManager 1 Charge when above 5A (minAmpsPerTWC).
May 20 22:00:53 twc python[19637]: 22:00:53 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_all_max_amps_for_slaves (value 0).
May 20 22:00:53 twc python[19637]: 22:00:53 TeslaAPI   8 Entering car_api_available - next step is to query Tesla API
May 20 22:00:53 twc python[19637]: 22:00:53 TeslaAPI   8 car_api_available returning True
May 20 22:00:59 twc python[19637]: 22:00:59 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_state (value 0).
May 20 22:01:01 twc python[19637]: 22:01:01 HASSStatus 4 Error connecting to HomeAssistant to publish sensor values
May 20 22:01:08 twc python[19637]: 22:01:08 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_cars_charging (value 0).
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     8 Evaluating Policy match (settings.chargeNowAmps), condition (gt), value (0), iteration (<built-in function iter>)
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     8 Policy conditions were not matched.
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     8 Evaluating Policy match (checkScheduledCharging()), condition (eq), value (1), iteration (<built-in function iter>)
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     8 Policy conditions were not matched.
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     8 Evaluating Policy match (tm_hour), condition (gte), value (6), iteration (<built-in function iter>)
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     8 Evaluating Policy match (tm_hour), condition (lt), value (20), iteration (<built-in function iter>)
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     8 Policy conditions were not matched.
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     8 Evaluating Policy match (none), condition (none), value (0), iteration (<built-in function iter>)
May 20 22:01:24 twc python[19637]: 22:01:24 Policy     7 All policy conditions have matched. Policy chosen is Non Scheduled Charging
May 20 22:01:51 twc python[19637]: 22:01:51 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_amps_max (value 0.0).
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     8 Evaluating Policy match (settings.chargeNowAmps), condition (gt), value (0), iteration (<built-in function iter>)
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     8 Policy conditions were not matched.
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     8 Evaluating Policy match (checkScheduledCharging()), condition (eq), value (1), iteration (<built-in function iter>)
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     8 Policy conditions were not matched.
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     8 Evaluating Policy match (tm_hour), condition (gte), value (6), iteration (<built-in function iter>)
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     8 Evaluating Policy match (tm_hour), condition (lt), value (20), iteration (<built-in function iter>)
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     8 Policy conditions were not matched.
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     8 Evaluating Policy match (none), condition (none), value (0), iteration (<built-in function iter>)
May 20 22:01:55 twc python[19637]: 22:01:55 Policy     7 All policy conditions have matched. Policy chosen is Non Scheduled Charging
May 20 22:01:59 twc python[19637]: 22:01:59 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_state (value 0).
May 20 22:02:09 twc python[19637]: 22:02:09 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_cars_charging (value 0).
May 20 22:02:15 twc python[19637]: 22:02:15 TWCSlave   1 SHB 0301: 00 00.00/00.00A 0000  M: 05 00.00/00.00A 0000
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     8 Evaluating Policy match (settings.chargeNowAmps), condition (gt), value (0), iteration (<built-in function iter>)
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     8 Policy conditions were not matched.
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     8 Evaluating Policy match (checkScheduledCharging()), condition (eq), value (1), iteration (<built-in function iter>)
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     8 Policy conditions were not matched.
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     8 Evaluating Policy match (tm_hour), condition (gte), value (6), iteration (<built-in function iter>)
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     8 Evaluating Policy match (tm_hour), condition (lt), value (20), iteration (<built-in function iter>)
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     8 Policy conditions were not matched.
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     8 Evaluating Policy match (none), condition (none), value (0), iteration (<built-in function iter>)
May 20 22:02:26 twc python[19637]: 22:02:26 Policy     7 All policy conditions have matched. Policy chosen is Non Scheduled Charging
May 20 22:02:52 twc python[19637]: 22:02:52 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_amps_max (value 0.0).
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     8 Evaluating Policy match (settings.chargeNowAmps), condition (gt), value (0), iteration (<built-in function iter>)
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     8 Policy conditions were not matched.
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     8 Evaluating Policy match (checkScheduledCharging()), condition (eq), value (1), iteration (<built-in function iter>)
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     8 Policy conditions were not matched.
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     8 Evaluating Policy match (tm_hour), condition (gte), value (6), iteration (<built-in function iter>)
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     8 Evaluating Policy match (tm_hour), condition (lt), value (20), iteration (<built-in function iter>)
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     8 Policy conditions were not matched.
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     8 Evaluating Policy match (none), condition (none), value (0), iteration (<built-in function iter>)
May 20 22:02:56 twc python[19637]: 22:02:56 Policy     7 All policy conditions have matched. Policy chosen is Non Scheduled Charging
May 20 22:03:00 twc python[19637]: 22:03:00 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_state (value 0).
May 20 22:03:02 twc python[19637]: 22:03:02 HASSStatus 4 Error connecting to HomeAssistant to publish sensor values
May 20 22:03:11 twc python[19637]: 22:03:11 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_cars_charging (value 0).
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     8 Evaluating Policy match (settings.chargeNowAmps), condition (gt), value (0), iteration (<built-in function iter>)
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     8 Policy conditions were not matched.
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     8 Evaluating Policy match (checkScheduledCharging()), condition (eq), value (1), iteration (<built-in function iter>)
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     8 Policy conditions were not matched.
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     8 Evaluating Policy match (tm_hour), condition (gte), value (6), iteration (<built-in function iter>)
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     8 Evaluating Policy match (tm_hour), condition (lt), value (20), iteration (<built-in function iter>)
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     8 Policy conditions were not matched.
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     8 Evaluating Policy match (none), condition (none), value (0), iteration (<built-in function iter>)
May 20 22:03:27 twc python[19637]: 22:03:27 Policy     7 All policy conditions have matched. Policy chosen is Non Scheduled Charging
May 20 22:03:54 twc python[19637]: 22:03:54 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_amps_max (value 0.0).
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     8 Evaluating Policy match (settings.chargeNowAmps), condition (gt), value (0), iteration (<built-in function iter>)
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     8 Policy conditions were not matched.
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     8 Evaluating Policy match (checkScheduledCharging()), condition (eq), value (1), iteration (<built-in function iter>)
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     8 Policy conditions were not matched.
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     8 Evaluating Policy match (tm_hour), condition (gte), value (6), iteration (<built-in function iter>)
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     8 Evaluating Policy match (tm_hour), condition (lt), value (20), iteration (<built-in function iter>)
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     8 Policy conditions were not matched.
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     8 Evaluating Policy match (none), condition (none), value (0), iteration (<built-in function iter>)
May 20 22:03:58 twc python[19637]: 22:03:58 Policy     7 All policy conditions have matched. Policy chosen is Non Scheduled Charging
May 20 22:04:02 twc python[19637]: 22:04:02 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_state (value 0).
May 20 22:04:12 twc python[19637]: 22:04:12 HASSStatus 8 Sending POST request to HomeAssistant for sensor sensor.twcmanager_0301_cars_charging (value 0).

No more logs from TWCManager after 22:00:53. Any guidance in diagnosing would be appreciated. 👍

Edit to add:
Charger has been unplugged from the car the entire time and is currently displaying a solid green status light.

https://github.com/dschutterop/dsmr

It doesn't make sense for someone setting this up to be modifying change-tracked code to configure their local policies. We should import the policy from the config file at startup; code can contain a simple default policy

I'm building something separate that will display a graph much like what the Powerwall app displays -- where energy came from, where it went -- but I'd like to support pointing to a TWCManager instance and showing car charging as a separate line on the graph from house consumption. In order to do that, I'd need to be able to grab the charge current over the last ~24 hours of history. (I think the Tesla API reports history with averages over 5 minute intervals, so I'd probably do the same here.)

I'll likely build this myself, but if you have suggestions about where to hook in, feel free to suggest!

I've noticed that if I override the actual current on the car's touch screen, it seems as though the max current seems to jump around, going to 21 and to 19, and then back up to the original setting. I'm guessing that this is TWCManager thinking that it needs to spike the amps in order to get the car to pickup the actual amps it is trying to tell it to use? When this happens, the car seems to then jump the actual current up and down from the setting I told it to use on the touch screen.

Is this a known issue?

The Powerwall EMS doesn't appear to be picking up the Powerwall's own state of charge. It would be nice to be able to set a minimum/target battery level in the config, such that Powerwall reports no available green energy until it has recharged to the target level.

It should be possible to instantiate all modules with the master object. The current approach doesn't cause any issues, but is unnecessary, and will pave the way for a more modular module infrastructure in the future.

Policy check is done once every 60 seconds, per the following

if ((self.lastPolicyCheck + 60) > time.time()):

https://github.com/ngardiner/TWCManager/blob/v1.1.7/lib/TWCManager/TWCMaster.py#L625

Are there any problems with reducing the policy check time to something much lower, like 5 seconds?

I have an application where I would like to use TWCManager inside an existing pythong script. I plan to make TWCManager.py a module that if imported, runs as a separate thread instead of a stand alone script. At the same time, I will not need MQTTControl, WebIPCControl, and MQTTStatus, so I'd like to add some logic that allows the script to continue to run if these do not exist.

Will you accept a pull request with these changes, or is it against your philosophy for this project? Just trying to decide how much time I should waste trying to make my modifications backwards compatible (for example, I could just completely remove MQTTControl, WebIPCControl, and MQTTStatus instead of making the code smart enough to check for their existence).

There isn't much dynamic about the current module instantiation code (which is entirely static) - would be nice instead to define a dict of various different type (source, control, status) of modules and then a loop to instantiate them all.

Provide the ability to use a different interface to serial (recommend a network interface such as a TCP socket) so that:

• Installations where the RS-485 interface is remote to the TWCManager machine could be supported
• Testing will be much easier

It appears that all the output from the policy selection is level 8, everything from the chosen policy to the individual parameter comparisons. It might be more useful to segment these across multiple levels, e.g.:

• New policy selected, Level 1
• Policy selection, Level 7
• Parameter comparison, Level 8
• Policy not selected, Level 8

This is a follow-up to a comment on an already-merged PR that I'm not sure if you saw. The current policy ordering is this:

• Charge Now
• User-defined before policy
• Green Energy
• Scheduled
• User-defined after policy
• Non-scheduled

I have two issues with this order, and I'd like to suggest a different one. As a premise to both, the "normal schedule" can be thought of as a block -- Green/Scheduled/Other. First, I'd like to suggest that this block is in the wrong order -- if Scheduled times overlap with the (necessarily broad) hours that Green Energy is checked, it's ignored. I think Scheduled/Green/Other makes more sense for this "normal scheduled" block.

(Perhaps even better would be to say that if multiple policies match, take the highest amps allowed by any of them, but that gets really tricky working with background tasks.)

If we do that, then conceptually the units are Charge Now (i.e. an explicit command) and Normal Schedule. Then the simple extensions to that that make sense are emergencies that justify overriding user commands, and exceptions to your normal schedule. So to me, the more sensible policy order would be:

• User-defined before policy
• Charge Now
• User-defined after policy
• Scheduled
• Green Energy
• Non-scheduled

In order to avoid breaking anyone using the current order, a simpler change might be to add one more extension point, and make it:

• User-defined emergency policy
• Charge Now
• User-defined before policy
• Scheduled
• Green Energy
• User-defined after policy
• Non-scheduled

In config.json, you have "wiringMaxAmpsPerTWC": 6 and "minAmpsPerTWC": 12. Is there a rationale for this?

I'm working on a solution for a simple view of the consumed/charged kwh, preferably recorded by car/model (M3 and non tesla), just to get an overview of how much kwh each of the cars consumed in a year.

I think this fork is the closest to beginn with and fits quite good, as my idea was to integrate it in HASS anyway and/or make it available via MQTT.

I use TWCManager in a passive way, in fakemaster = 2 mode and like to capture the consumed kwh (on newer fw). As a second step I'm planing to readout part of the VIN to figure out if its a telsa or not to assign from-to charged kwh to the individual car.

is it possible to integrate kWhDelivered/kWhCounter msgpart from debug output in HASS and MQTT the same was as "total_amps_in_use", "totalAmpsInUse" ?

22:23:40 TWCManager 1 TWC Manager starting as fake Master with id 7777 and sign 77
22:23:41 TWCManager 9 Rx@: () FD EB 25 87 00 00 03 9C 00 F6 00 F0 00 F6 00 00 00 00 00 12
22:23:41 TWCManager 1 VRS XXX: 924kWh 246V 240V 246V

is currently Restart=on-abort

this caused it to not restart for some for now undetermined reason last night. I would propose

Restart=always
StartLimitInterval=60s
StartLimitBurst=5

to ensure its restarted unless stopped by systemd, but also avoid spamming logs if something goes wonky?

Based off of Amber: https://www.amberelectric.com.au/pricing

The idea is that instead of increasing/decreasing based on green energy generation, the charge rate could be increased/decreased based on proximity to a target maximum real-time wholesale price. This is more a generic concept rather than an actual implementation as amber do not yet have an exposed API, but a module template to do this would be useful as I am sure there are similar platforms globally.

In various places throughout the code, an apparent power is computed using an assumed line voltage of 240V. Seems like line voltage is not always constant. Also, is there any evidence that the power factor of the onboard charger in the car maintains a power factor of 1.0 and that the sine wave does not have distortion?

I'm wondering if the RS-485 protocol supports providing the voltage in addition to amps? If that were the case, even if the sine wave isn't pure and the power factor is not exactly 1.0, it seems like it is still going to be an improvement to compute an apparent power using a measured voltage.

According to https://www.reddit.com/r/teslamotors/comments/f5dbf7/psa_power_api_changes/, the cloud API endpoint has changed for Powerwall. This might not impact the local endpoint, or the change might be coming in a future firmware update, but it needs to be validated.

The fix should be simple regardless, but I'm not sure which would be less breaking to any existing users. The comments in config.json suggest setting a negative value for greenEnergyAmpsOffset to leave some buffer, but the current state of check_green_energy() treats this as a consumption report, meaning that a negative value will reduce the consumption reported by the other modules.

Do we update the comments to suggest a positive number, or do we modify check_green_energy() to multiply by negative one? Or do we assume that no one wants to ignore part of their consumption and abs() it instead?

There are still globals in TWCManager to be checked & removed:

data = ''
dataLen = 0
ignoredData = bytearray()
msg = bytearray()
msgLen = 0
lastTWCResponseMsg = None

numInitMsgsToSend = 10
msgRxCount = 0

idxSlaveToSendNextHeartbeat = 0
timeLastkWhDelivered = time.time()
timeLastkWhSaved = time.time()
timeLastHeartbeatDebugOutput = 0

webMsgPacked = ''
webMsgMaxSize = 300
webMsgResult = 0

timeTo0Aafter06 = 0
timeToRaise2A = 0

Powerwall's Storm Watch mode is not exposed via the local API that anyone has found so far. However, it is exposed on the cloud endpoint. Particularly since the Tesla API tokens are already in the config for interacting with the Vehicle API, it should be feasible to check the cloud API for Storm Watch periodically. Given that the point of Storm Watch is to trigger well in advance of it actually being needed, it would probably be sufficient to poll every 20-30 minutes.

This does break the current invariant that an unused charger doesn't continue to hit the cloud endpoint until the car is charged again. Possible avenues I see:

• Change the invariant. If you set this up, you expect it to hit the API.
• Require explicit opt-in for the Powerwall config to access the cloud API.
• Use the current API token, but never renew it from Powerwall checks. Eventually, that token stops working if no car APIs renew it along the way.

Currently, a single option (using the Tesla API) exists for stopping car charging. If the API interaction fails, the car continues to charge at the minimum amps for the charger. This aims to provide an alternative for those who don't want to use the Tesla API (which is now modular as of v1.1.4 onwards) and want to instead stop TWCManager from responding to slaves.

This method may result in cars not resuming charge after charging restarts, and may require re-plugging the charger cable. For some, this will be acceptable (and for others, it will not). Providing the option is the preferred way forward.

Hi,

Im running the latest version (dated 2020-07-05) and when trying to debug a problem of "not stopping charge with GreenEnergy policy" I saw this in log...

TWCSlave 10 astimezone() cannot be applied to a naive datetime

That same astimezone() is also used in TWCMaster so maybe check that as well.

During a Green Energy policy, the code does the following (omitting steps that don't matter here):

1. Apply the output of getMaxAmpsToDivideGreenEnergy() as the max charging current
2. Queues the background task to run check_green_energy() and update numbers
3. Waits policyInterval seconds
4. GOTO 1

This means that the data being acted on is roughly policyInterval (30) seconds old, and is immediately replaced by newer, better data just after it gets used. It seems like what we really want in the green energy policy is to completely omit setting current in the policy, and have the background task set the charge current instead.

I have a PR that makes this change, but it seems dramatic enough that I'd like to make sure I'm not missing something key.

Most likely due to the output being printed within TWCManager, where the green energy check is then queued to be performed in the update thread. May need to move the status print function to the update thread.

11:07:14: Solar generating 1074W, Consumption 845W, Charger Load 0W
          Limiting car charging to 4.47A - 3.52A = 2.28A.
          Charge when above 6A (minAmpsPerTWC).

11:08:15: Solar generating 1074W, Consumption 845W, Charger Load 0W
          Limiting car charging to 4.47A - 3.52A = 0.95A.
          Charge when above 6A (minAmpsPerTWC).

The first value printed lags the new green energy measurement, hence the incorrect total. The 3rd value always appears to be one measurement behind after a green energy update.

While doing some testing around basic recording of charging sessions for vehicles, I've found that the current VIN detection may not work in all cases. I connected a vehicle to a Slave TWC and no VIN response was received from the Slave TWC when queried. I will need to do more testing to reproduce the actual behavior. Reconnecting the vehicle to the TWC allowed the VIN to be detected successfully.

We may need to consider if a more robust mechanism is required, such as delayed subsequent queries of VIN if the first query is not responded to.

Hi,
Just installed and running TWCManager on rpi zero W.
My setup is 3 phase, 40A breaker, with solar generation monitoring by one device (Sunnyboy inverter) and consumption monitoring by another device (smappee). Since there were no modules fitting my use-case, I have frankensteined together a new MQTT EMS module to integrate with TWCManager. It seems to be working correctly, I think.

One of my problems is that when TWCManager calls setMaxAmpsToDivideAmongSlaves(), the actual slave usage is always about 3 times what was allowed. ie. If master calculated max as 5A, the slave's reportedAmpsActual would be about 15A.
As a test, I modified TWCMaster.py to account for 3 phase electricity by simply dividing the amps by 3 in the call to setMaxAmpsToDivideAmongSlaves(). The result appears to be correct, give or take a small fluctuations as generation increases or decreases.
I have set wiringMaxAmpsAllTWCs=16, wiringMaxAmpsPerTWC=16, minAmpsPerTWC=3.
Please let me know if this was a reasonable thing to do, or if I am totally wrong and that the code already caters for 3 phase.

The second problem I'm seeing is that the charging is flapping on/off a lot instead of ramping the amps up/down as appropriate in response to the fluctuating solar generation. ie. scattered clouds causing frequent high and low generation.
I do see a few rare times the charging amps have adapted from, say 16A to 12A to 6A, but most often the TeslaAPI is called every minute or so to start and then stop the charging. I have set subtractChargerLoad to true, but the issue remains.

Third question is; Is there a minimum charge rate at which the slave will begin charging? I seem to only see charging begin when the minimum is 5A (or is it 6A?). This is independent of the minAmpsPerTWC setting. My slave heartbeat shows:
SHB 1820: 09 00.00/06.00A 0000 0000 M: 09 00.00/02.85A 0000 0000
Is that telling me the min charge rate is 6A?

In order to create policy requirements that make assertions about the state of the Powerwall (e.g. grid offline), the policyValue() function should be able to access the modules by name. In the current architecture, they're not reachable from that function. Fixing this might also be a good opportunity to fix #10 along the way, e.g. putting the modules into a dictionary and processing policy values against keys in the dictionary rather than hard-coding module names in the function.

Current Tesla API integration doesn't appear to work correctly. This is more than likely due to special characters in Tesla passwords which interfere with the curl shell commands. A rewrite using requests module rather than curl shell commands is the best approach to resolve this.

Need a comma on the end of this line:

https://github.com/ngardiner/TWCManager/blob/v1.2.0/etc/twcmanager/config.json#L201

This would only be applicable to a subset of TWCs, since not all of them support reporting the VIN. There was a Reddit post where someone was concerned about having the TWC outside, since anyone could pull up during the day and charge. So here's a random idea:

Now that we support getting the VIN from the TWC, it would be fairly straightforward to check that the VIN matches one of the VINs on the Tesla account and/or an explicit list in the config file, and stop responding to that TWC (or send a stop-charging command) if an unauthorized car starts charging.

The harder pieces would be:

• Recovery; if we do that, we won't know when the offending vehicle is gone. Maybe just clear it at the next policy change, which means that the Charge Now button on the web interface unlocks it?
• Support and messaging; if the feature is configured and the TWC doesn't support giving us the VIN, we would need to prominently display an error.

Documentation, especially for modules are lacking. Target a few doco improvements per release for the next few releases leading up to v1.2.0:

v1.1.4:

• Fronius EMS Module done
• Powerwall2 EMS module done
• TED EMS module done

v1.1.5:

• Finish installation documentation done
• HASS EMS Module done
• HTTP Control Module done
• MQTT Control Module inprog
  • Details on topics and values to control
• WebIPC Control Module inprog

Future

• HASS Status Module
• MQTT Status Module

Why not set it to the maximum instead? Or allow it to be set by the payload of the MQTT message? (Filing an issue instead of a PR because I'm curious what the rationale is.)

Since you can set the charge limit via the Tesla API, would be nice to have the desired charge as a parameter for each charge mode (e.g. only charge to 50% during scheduled charging, but to 90% when on green power).

It would be good to check currentVIN when requesting vehicles to stop charging via API.

It's probably more complex than I am giving it credit for, though. For example, two Slave TWCs, one with VIN capability and one without. We drop below minAmpsPerTWC - what do we do? Perhaps what we need is a quorum where if all Slave TWCs are marked as supporting VINs, we only send stop messages to those VINs - otherwise we stop all vehicles per today's behaviour. Or is this just an overly complex rabbit hole to go down?

in addition to the make approach, would using virtualenv and deploying the framework via pip make sense to ensure integrity, consistency and that the python dependencies are met ?

something like:

mkdir /usr/local/twcmanager
cd /usr/local/twcmanager
virtualenv -ppython3 .
source bin/activate
pip install twcmanager-1.3.tar.gz

/usr/local/twcmanager/etc -> location for config.json and twcmanager.service (rather than /etc/twcmanager)
/usr/local/twcmanager/bin -> TWCManager.py
etc,...

this could then be a nice portable package ?

Originally posted by @nean-and-i in #85 (comment)

Currently, the Powerwall2 EMS module does not support password authentication for Powerwall2.

In the function policyValue in TWCMaster.py there is the variable strstart = 10. However, len("settings.") = 9. Since python indexes from 0, why do you set strstart = 10 ? I think this is a bug.

As a result of the separation effort to modularise TWCManager, TWCManager as a slave is broken.

There's some slave related comms that need to move from TWCManager to TWCMaster.

Take a look at slaveHeartbeatData withhin TWCSlave. It comes from TWCManager. It involves doing bitwise manipulation of the variable, so a getter and setter function probably doesn't make sense. Should be fairly easy to move over, could test by changing the charger rotary switch.

Low priority.

debugLog should be self.debugLog

Please see

https://github.com/ngardiner/TWCManager/blob/v1.1.7/lib/TWCManager/TWCMaster.py#L747

Hi,

Do I read the log correctly that the script is trying to send a "STOP CHARGE" to the car (last 5 lines)?

09:30:33 Policy     8 Evaluating Policy match (tm_hour), condition (gte), value (6)
09:30:33 Policy     8 Evaluating Policy match (tm_hour), condition (lt), value (20)
09:30:33 Policy     8 Evaluating Policy match (settings.hourResumeTrackGreenEnergy), condition (lte), value (tm_hour)
09:30:33 Policy     7 All policy conditions have matched. Policy chosen is Track Green Energy
09:30:33 TeslaAPI   8 Entering car_api_available - next step is to query Tesla API
09:30:33 TeslaAPI   8 car_api_available returning True
09:30:33 TWCManager 1 Green energy generates 0W, Consumption 0W, Charger Load 1211W
09:30:33 TWCManager 1 Limiting charging to 0.00A - 0.00A = 0.00A.
09:30:33 TWCManager 1 Charge when above 6A (minAmpsPerTWC).
09:30:43 TeslaAPI   8 Entering car_api_available - next step is to query Tesla API
09:30:43 TeslaAPI   8 car_api_available returning True
09:30:43 TeslaAPI   8 startOrStop is set to stop
09:30:44 TeslaAPI   8 Car API cmd<Response [200]>
09:30:44 TeslaAPI   4 CARNAME: stop charge response{'response': {'result': True, 'reason': ''}}

It doesn't seem to work as the car is charging and not stopping at all!? Is this a bug on my CAR or something? Because my Powerwall is below 90% and should use the solar energy only to charge it till it's 90% and then deliver energy for the car.