V1.3.0 - Export meter not working as expected with TWCManager

[cods4]

I have recently got this running again after installing a second TWC. In the process I decided to re-install raspbian etc and the latest V1.3.0 of TWCManager and reconfigure TWCManager from scratch.

I am almost certain that before these changes, I was giving TWCM a single Consumption value from home assistant called sensor.main_power. This was coming directly from a Shelly EM3 which monitors my grid current, voltage, power etc. When my house and solar system is exporting to the grid it reads negative power, and when I am buying energy from the grid it shows positive power.

When I configure this HASS entity as a Consumption meter under the HASS source, TWCM doesn't behave at all like I think it did before. When we are exporting power, everything reads zero, and when we are importing power I get positive consumption readings.

I have also tried the MQTT source using the some value taken directly from the Shelly EM3 and I got the same results.

What I want to do with my main_power sensor is have it feed directly into the 'solar surplus' variable in TWCM when it's negative, and into the Consumption variable when it is positive. What am I doing wrong here?

Here's my config.json

``{ "config": {

The settings path will store the dynamic settings which are defined via the web

    # interface
    "settingsPath": "/etc/twcmanager",

    # Set wiringMaxAmpsAllTWCs to the maximum number of amps your charger wiring
    # can handle. I default this to a low 6A which should be safe with the minimum
    # standard of wiring in the areas of the world that I'm aware of.
    # Most U.S. chargers will be wired to handle at least 40A and sometimes 80A,
    # whereas EU chargers will handle at most 32A (using 3 AC lines instead of 2 so
    # the total power they deliver is similar).
    # Setting wiringMaxAmpsAllTWCs too high will trip the circuit breaker on your
    # charger at best or START A FIRE if the circuit breaker malfunctions.
    # Keep in mind that circuit breakers are designed to handle only 80% of their
    # max power rating continuously, so if your charger has a 50A circuit breaker,
    # put 50 * 0.8 = 40 here.
    # 40 amp breaker * 0.8 = 32 here.
    # 30 amp breaker * 0.8 = 24 here.
    # 100 amp breaker * 0.8 = 80 here.
    # IF YOU'RE NOT SURE WHAT TO PUT HERE, ASK THE ELECTRICIAN WHO INSTALLED YOUR
    # CHARGER.
    "wiringMaxAmpsAllTWCs": 32,

    # If all your chargers share a single circuit breaker, set wiringMaxAmpsPerTWC
    # to the same value as wiringMaxAmpsAllTWCs.
    # Rarely, each TWC will be wired to its own circuit breaker. If you're
    # absolutely sure your chargers each have a separate breaker, put the value of
    # that breaker * 0.8 here, and put the sum of all breakers * 0.8 as the value of
    # wiringMaxAmpsAllTWCs.
    # For example, if you have two TWCs each with a 50A breaker, set
    # wiringMaxAmpsPerTWC = 50 * 0.8 = 40 and wiringMaxAmpsAllTWCs = 40 + 40 = 80.
    "wiringMaxAmpsPerTWC": 32,

    # https://teslamotorsclub.com/tmc/threads/model-s-gen2-charger-efficiency-testing.78740/#post-1844789
    # says you're using 10.85% more power (91.75/82.77=1.1085) charging at 5A vs 40A,
    # 2.48% more power at 10A vs 40A, and 1.9% more power at 20A vs 40A.  This is
    # using a car with 2nd generation onboard AC/DC converter (VINs ending in 20000
    # and higher).
    # https://teslamotorsclub.com/tmc/threads/higher-amp-charging-is-more-efficient.24972/
    # says that cars using a 1st generation charger may use up to 30% more power
    # at 6A vs 40A!  However, the data refers to 120V 12A charging vs 240V 40A
    # charging. 120V 12A is technically the same power as 240V 6A, but the car
    # batteries need 400V DC to charge and a lot more power is wasted converting
    # 120V AC to 400V DC than 240V AC to 400V DC.
    #
    # The main point is 6A charging wastes a lot of power, so we default to charging
    # at a minimum of 12A by setting minAmpsPerTWC to 12. I picked 12A instead of 10A
    # because there is a theory that multiples of 3A are most efficient, though I
    # couldn't find any data showing that had been tested.
    #
    # Most EU chargers are connected to 230V, single-phase power which means 12A is
    # about the same power as in US chargers. If you have three-phase power, you can
    # lower minAmpsPerTWC to 6 and still be charging with more power than 12A on
    # single-phase.  For example, 12A * 230V * 1 = 2760W for single-phase power, while
    # 6A * 230V * 3 = 4140W for three-phase power. Consult an electrician if this
    # doesn't make sense.
    #
    # https://web.archive.org/web/20180807013639/https://forums.tesla.com/forum/forums/charging-lowest-amperage-purposely
    # and https://teslamotorsclub.com/tmc/threads/low-amp-charging.197800/
    # says another reason to charge at higher power is to preserve battery life.
    # The best charge rate is the capacity of the battery pack / 2.  Home chargers
    # can't reach that rate, so charging as fast as your wiring supports is best
    # from that standpoint.  It's not clear how much damage charging at slower
    # rates really does.
    "minAmpsPerTWC": 8,

    # If the system rapidly changes its mind about whether to start or stop charging,
    # this parameter keeps charging / not charging until the decision remains stable
    # for this many seconds.
    #"startStopDelay": 60,

    # Depending on your environment and experience with GPS location quality, you
    # may want to choose how close a car needs to be to your home location to be
    # considered "at home". Value is given in feet, one foot is about 0.3 meters.
    # The default value is 10560 feet (2 miles), as cars in the past had quite some
    # issues with location accuracy. Do not set this too low, but about 1000 feet
    # should be safe usually.
    # Note the covered area is actually not a circle, but a square with a side length
    # of 2 * atHomeRadius (measured east-west & south-north).
     "atHomeRadius": 1000,

    # Newer TWCs can report actual voltages.  For older TWCs, you can specify
    # what voltage should be assumed and whether the power is single (1) or
    # 3-phase.
    "defaultVoltage": 230,
    "numberOfPhases": 1,

    # As I observed different reactive power changing with the the amps used,
    # I introduce a real power variable for minAmps and maxAmps
    # For my installation there was 0.90 at 6 amps and 0.93 at 20 amps.
    # You can comment that in, if you want to try this.
    # "realPowerFactorMinAmps": 0.9,
    # "realPowerFactorMaxAmps": 0.93,

    # If green energy dips below the target charge amount while already charging,
    # how much extra current should be drawn to keep charging?  This avoids frequently
    # stopping and starting charging on a day with variable solar output, at the cost
    # of drawing energy from sources other than solar.
    "greenEnergyFlexAmps": 6,

    # If you want to use start charging with greenEnergyFlexAmps as it delays stopping
    # you have to set this config to true
    "useFlexAmpsToStartCharge": true,

    # If the conditions for green energy briefly fail to match, how long should the
    # Track Green Energy policy continue to run?  (Mainly useful if you're adding
    # non-time-based restrictions below.)
    #"greenEnergyLatch": 15,

    # In some environments, the consumption meter value that we obtain will
    # include the charger's consumption, whilst others will not.
    # This switch, if set to true, will subtract the charger's load from the
    # consumption value, ensuring that the charger itself doesn't register
    # in your solar consumption value.

    # If your solar consumption value does include the charger and you don't
    # set this option, you'll see charging consistently stop after a short
    # time interval, due to the available amps being set below minimum charge.
    "subtractChargerLoad": false,

    # If your EMS does not return total PV generation but only the power
    # delivered back to the grid, set treatGenerationAsGridDelivery to
    # true.
    "treatGenerationAsGridDelivery": true,

    # The minChargeLevel parameter determines the minimum acceptable SOC
    # state for any monitored vehicle. If the SOC is below this value,
    # the car will not be stopped from charging (even if we are not
    # generating sufficient energy). This value is disabled by default;
    # you will need to un-comment it to have it take effect.
    #"minChargeLevel": 10,

    # The cloudUpdateInterval determines how often to poll certain
    # data retrieved from the Tesla API to evaluate policy.
    "cloudUpdateInterval": 1800,

    # These parameters enable you to specify different charge limits
    # for different charging policies.  The car's 'outside' limit
    # will be restored whenever GPS indicates the car has left home.
    #
    # Valid settings are integers 50-100, or use -1
    # to keep the car's 'outside' limit.  -1 is the default.
    #"chargeNowLimit": 100,
    #"greenEnergyLimit": 90,
    #"scheduledLimit": 50,
    #"nonScheduledLimit": -1,

    # Deprecated, use logLevel instead
    # Choose how much debugging info to output.
    # 0 is no output other than errors.
    # 1 is just the most useful info.
    # 2-8 add debugging info
    # 9 includes raw RS-485 messages transmitted and received (2-3 per sec)
    # 10 is all info.
    # 11 is more than all info.  ;)
    # "debugLevel": 1,

    # Level     Numeric  debugLevel_equiv
    #
    # CRITICAL  50
    # ERROR     40        0     no output other than errors.
    # WARNING   30
    # INFO      20        1     just the most useful info.
    # INFO2     19        2     add debugging info
    # INFO3     18        3     add debugging info
    # INFO4     17        4     add debugging info
    # INFO5     16        5     add debugging info
    # INFO6     15        6     add debugging info
    # INFO7     14        7     add debugging info
    # INFO8     13        8     add debugging info
    # INFO9     12        9     includes raw RS-485 msgs tx and rx (2-3 per sec)
    # DEBUG     10       10     all info.
    # DEBUG2     9       11     more than all info.  ;)

    "logLevel": 13,

    # Choose whether to display milliseconds after time on each line of debug info.
    "displayMilliseconds": false,

    # Webhooks can be triggered using either GET or POST methods.
    # By default, they receive a POST of the current status; uncomment for GET.
    #"webhookMethod": "GET",

    # Normally we fake being a TWC Master using fakeMaster = 1.
    # Two other settings are available, but are only useful for debugging and
    # experimenting:
    #   Set fakeMaster = 0 to fake being a TWC Slave instead of Master.
    #   Set fakeMaster = 2 to display received RS-485 messages but not send any
    #                      unless you use the debugging web interface
    #                      (index.php?debugTWC=1) to send messages.
    "fakeMaster": 1
},

# The interface section of the configuration is where we configure the
# way in which we talk to the TWC Slaves. This is usually going to be
# RS485, which is enabled by default.
#
# Note that only one interface can be enabled for a valid configuration.
# If you enable more than one, only the first enabled interface will be used
"interface": {
  "Dummy": {
    "enabled": false,

    # The dummy module is used for testing. It will simulate an actual
    # slave TWC for the purpose of offline testing of TWCManager.
    # Most people would not enable this module.
    # This should be a two-byte ID
    "twcID": "AB"
  },
  "RS485": {
    "enabled": true,

    # TWC's RS485 port runs at 9600 baud which has been verified with an
    # oscilloscope. Don't change this unless something changes in future hardware.
    "baud": 9600,

    # This value allows overriding of the default 26 second heartbeat timeout for Slave TWCs.
    # This value should work in hard-wired systems, but if you are using network
    # to RS485 adapters and experiencing occasional network loss or latency, this
    # value can be tuned to extend the timeout.
    #"slaveTimeout": 26,

    # Most users will have only one ttyUSB adapter plugged in and
    # '/dev/ttyUSB0' will work. If not, run 'dmesg |grep ttyUSB' on the
    # command line to find your rs485 adapter
    # If you're using a non-USB adapter like an RS485 shield, the value may need to
    # be something like '/dev/serial0'.
    "port": "/dev/ttyUSB0"

    # Note that the RS485 module can also handle simple raw or rfc2217
    # TCP connections. If your requirements are simple, you could use
    # a URL such as:
    # "port": "rfc2217://<host>:<port>"     or
    # "port": "socket://<host>:<port>"

  },
  "TCP": {
    "enabled": false,

    # NOTE: This interface is in active development. Please use the RS485
    # interface instead
    # The TCP module allows communications over a TCP listener or client
    # socket. This can be used to integrate with network-based RS485
    # interfaces.

    # Listen determines if we open a listening socket or connect to
    # the server address below.
    "listen": false,
    "server": "192.168.1.2"
  }
},
"control": {
  "HTTP": {
    "enabled": true,
    "listenPort": 8080
  },
  "MQTT": {
    "enabled": true,
    "brokerIP": "192.168.21.30",
    "topicPrefix": "TWC",
    "username": "mqttuser",
    "password": "mqttpassword"
  },
  "OCPP": {
      "enabled": false,
      "serverPort": 9000
  }

},

# In the below policy segment of the configuration, we can tune the behaviour
# of the policy engine. By default, the policy engine will:
# - Evaluate any user defined extensions in the emergency section below
# - Check for the configuration of a "Charge Now" option, if so, start charging
#   at the specified rate for the specified time.
# - Evaluate any user defined extensions in the before section below
# - During Scheduled Charging hours, charge at the scheduled rate.
# - Poll Green Energy Sources to see if they are supplying enough energy to charge
#   (and within schedule), and if so, adjust charge rate to generated energy value
# - Evaluate any user defined extensions in the after section below
# - Outside Scheduled Charging, charge at unscheduled charge rate
"policy":{
  # By default, EMS modules are polled only when the data is needed
  # to track green energy. If you would like to always poll EMS for
  # display purposes, uncomment this.
  #
  # This will not work for custom policies which specify their own
  # background task.
  #"alwaysPollEMS": true,

  "engine":{
    "policyCheckInterval": 30
  },
  # NOTE: Override and Extend are mutually exclusive options. Once you override, you
  # can no longer extend the inbuilt policy.
  # Using the extend feature below, you can add extra rules into the charging policy.
  "extend":{
    # Rules in the emergency section are evaluated before the Charge Now rule
    #
    # They should primarily be used to abort charging when necessary.
    "emergency":[
    ],
    # Rules in the before section here are evaluated after the Charge Now rule
    "before":[
    ],
    # Rules in the after section here are evaluated before the Unscheduled Charging
    # rule at the end of the policy.
    "after":[
    ],

    # Rather than defining additional policies, these values place additional constraints
    # on the built-in policies.
    "restrictions":{
      #"Track Green Energy":{
      #  "match":[],
      #  "condition":[],
      #  "value":[]
      #},
      #"Charge Now":{
        #  "match":[],
        #  "condition":[],
        #  "value":[]
        #},
    },

    # This permits defining webhooks for the built-in policies
    "webhooks": {
      #"Scheduled Charging": {
      #  "enter": "http://ift.tt/your_url_here",
      #  "start": "http://ift.tt/your_url_here",
      #  "stop": "http://ift.tt/your_url_here",
      #  "exit": "http://ift.tt/your_url_here"
      #}
      #"Track Green Energy": etc.
      #"Charge Now": etc.
      #"Non Scheduled Charging": etc.
    }
  },
  # NOTE: Override and Extend are mutually exclusive options. Once you override, you
  # can no longer extend the inbuilt policy.
  # If you are planning on using this feature, please consider first using the
  # extend option above, which probably lets you do what you need to do, but avoids
  # totally replacing the charge policy which may get improved over time in the
  # codebase. If you do override this, you may need to keep it in sync with the code
  # in future.
  "override": [
  # { "name": "Charge Now",
  #   "match": [ "settings.chargeNowAmps", "settings.chargeNowTimeEnd", "settings.chargeNowTimeEnd" ],
  #   "condition": [ "gt", "gt", "gt" ],
  #   "value": [ 0, 0, "now" ],
  #   "charge_amps": "settings.chargeNowAmps",
  #   "charge_limit": "config.chargeNowLimit" },

  # { "name": "Scheduled Charging",
  #   "match": [ "checkScheduledCharging()" ],
  #   "condition": [ "eq" ],
  #   "value": [ 1 ],
  #   "charge_amps": "settings.scheduledAmpsMax",
  #   "charge_limit": "config.scheduledLimit" },

  # { "name": "Track Green Energy",
  #   "match": [ "tm_hour", "tm_hour", "settings.hourResumeTrackGreenEnergy" ],
  #   "condition": [ "gte", "lt", "lte" ],
  #   "value": [ 6, 20, "tm_hour" ],
  #   "charge_amps": "getMaxAmpsToDivideGreenEnergy()",
  #   "background_task": "checkGreenEnergy",
  #   "charge_limit": "config.greenEnergyLimit" },

  # { "name": "Non Scheduled Charging",
  #   "match": [ "settings.nonScheduledAction" ],
  #   "condition": [ "lt" ],
  #   "value": [3],
  #   "charge_amps": "settings.nonScheduledAmpsMax",
  #   "charge_limit": "config.nonScheduledLimit" },

  ]
},
"logging":{
    # Logging configuration controls where status messages about the TWC
    # and charging sessions are logged. By default, we log to console and
    # not to file. Consider what logging to file may mean if you're using
    # a pi, it may mean considering alternatives such as a remote database
    # to reduce write cycles.
    "Console": {
        "enabled": true,
        # simple logging format omits timestamp and colorization
        #"simple": true
    },
    "FileLogger": {
      "enabled": false,
      # The path under which the various log files will be stored.
      # Make sure the user which runs the TWCManager process can write to
      # this directory.
      "path": "/etc/twcmanager/log",
      # The mute parameter allows turning specific logging on or off.
      # In the example below, charge sessions are logged, but not the
      # regular charger status messages. These are valid under any of the
      # logging modules
      # For the debug output, you can mute Log Levels greater than the
      # value specified here.
      "mute":{
          "ChargeSessions": false,
          "GreenEnergy": false,
          "SlavePower": false,
          "SlaveStatus": false,
          "DebugLogLevelGreaterThan": 1
      }
    },
    "Sentry": {
      "enabled": true,
  # The DSN can be found in Sentry under SDK Setup of a project
  "DSN": "",
      # The mute parameter allows turning specific logging on or off.
      # In the example below, charge sessions are logged, but not the
      # regular charger status messages. These are valid under any of the
      # logging modules
      # For the debug output, you can mute Log Levels greater than the
      # value specified here.
      "mute":{
          "ChargeSessions": false,
          "GreenEnergy": false,
          "SlavePower": false,
          "SlaveStatus": false,
          "DebugLogLevelGreaterThan": 1
      }
    },
    "CSV": {
        "enabled": false,
        # The path under which the various csv files will be stored.
        # Make sure the user which runs the TWCManager process can write to
        # this directory.
        "path": "/etc/twcmanager/csv",
        # The mute parameter allows turning specific logging on or off.
        # In the example below, charge sessions are logged, but not the
        # regular charger status messages. These are valid under any of the
        # logging modules
        "mute":{
            "ChargeSessions": false,
            "GreenEnergy": true,
            "SlavePower": true,
            "SlaveStatus": true
        }
    },
    "MySQL": {
        "enabled": false,
        "host": "1.2.3.4",
        "port": 3306,
        "database": "twcmanager",
        "username": "twcmanager",
        "password": "twcmanager"
    },
    # SQLite is only in prototype phase at this point. More work required
    # before this will be a working logging target
    "SQLite": {
        "enabled": false,
        "path": "/etc/twcmanager/twcmanager.sqlite"
    }
},
"sources":{
    # This section is where we configure the various sources that we retrieve our generation and consumption
    # values for our solar system from.
    # To use a particular interface, set the enabled flag to true (or it will be ignored) and fill in the
    # relevant fields to allow the interface to connect to the system. Whilst you can have multiple interfaces
    # configured simultaneously, currently we will only add together the values recieved from each. This might be
    # useful if you have one interface that provides generation detail and another that provides consumption
    # detail, but if both systems provided both values, it would be duplicated.
  # The DSMRreader EMS module subscribes to the below MQTT topic to read Consumption/Generation values
    "DSMRreader": {
      "enabled": false,
      "brokerIP": "192.168.1.2",
      "username": "mqttuser",
      "password": "mqttpass",
      "topic": "dsmr/json",
    },
  # The Efergy server allows fetching of consumption from https://engage.efergy.com/ token is needed
    "Efergy": {
        "enabled": false,
        "token": "abcd1234"
    },
    "Enphase": {
        "enabled": false,

        # Note that Enphase is an either/or, either Cloud or Local
        # Enabling both of these sections will not give you the intended
        # outcome.
        #
        # Cloud API:
        "apiKey": "ABC123",
        "systemID": "12345",
        "userID": "4d6a51330a"
        # Local API:
        #"serverIP": "192.168.1.2",
        #"serverPort": 80

    },
    "Fronius": {
        "enabled": false,
        "serverIP": "192.168.1.2"
    },
    # Growatt: Uses a Growatt pypi package to very easily pull the data
    # useBatteyAt describes at whihc SOC the system will add the battery's maxOutput to the pool of available power
    # batteryMaxOutput is the maximum watt that the battery will output calculated by dividing battery Wh in two,
    # in my case that's 9600wh and half of that is 4800
    "Growatt": {
        "enabled": false,
        "username":"username",
        "password":"password",
          "useBatteryAt":"80",
          "batteryMaxOutput":"4800",
          "useBatteryBefore":"15:00"
    },
    "HASS": {
  # The HASS module allows fetching of consumption and generation statistics from HomeAssistant sensors.
        "enabled": true,

  # The IP address and port of the HomeAssistant front-end
        "serverIP": "homeassistant.mydomain.com",
        "serverPort": "443",
        "useHttps": true,

  # To obtain a HASS API key, via browser, click on your user profile, and
  # add a Long-Lived Access Token. Place it in the following variable:
        "apiKey": "ABC1234",

  # For HomeAssistant, the two settings below must be customized to point to the specific sensor
  # names you use within HomeAssistant. There is no default or common value for this, so it will
  # require customization to work correctly.
  # If you do not track one of these values (generation or consumption) via HASS, leave the parameter
  # blank, and it will not be retrieved.
        "hassEntityConsumption": "sensor.main_power",
        "hassEntityGeneration":  ""
    },
    "IotaWatt": {
  # The IotaWatt module allows fetching of consumption and generation statistics from IotaWatt outputs.
        "enabled": false,

  # The IP address of the IotaWatt front-end
        "serverIP": "192.168.1.1",

  # For IotaWatt, the two settings below must be customized to point to the specific outputs
  # you have created. There is no default or common value for this, so it will require customization to
  # work correctly. If you do not track one of these values (generation or consumption) via IotaWatt,
  # leave the parameter blank, and it will not be retrieved.
        "outputConsumption": "Total_Consumption",
        "outputGeneration":  "Solar"
    },
    "MQTT": {
      "enabled": false,
      "brokerIP": "192.168.21.30",
  # The MQTT EMS module subscribes to the below topics to read Consumption/Generation values
      "username": "mqttuser",
      "password": "mqttpassword",
      "topicConsumption": "shellies/shellyem3-C45BBE6C19B0/emeter/0/power",
      "topicGeneration": ""
    },
    "P1Monitor":{
      # Support for P1 Monitor API (https://www.ztatz.nl/)
      # Reads /api/v1/phase
      "enabled": false,
      "serverIP":"192.168.1.2",
      # Amount of samples to take average from (min 1, max 10, default 1)
      "samples": 1
    },
    "OpenWeatherMap": {
        "enabled": false,
        #your position on earth, use maps.google and copy from the URL parameters after the @ sign
        "Latitude": 41.870978,
        "Longitude": 11.853508,
        #APIKey from https://openweathermap.org/
        "APIKey": "xyz-EDIT-ME-xyz",
        #a 12 items array with the best kW reached on a day in that month
        "PeakKW": [2, 4, 6, 6, 6.5, 6.9, 6.5, 6.0, 5.5, 4.5, 3, 2]
    },
  # Tesla Powerwall2
  # This module fetches both consumption and solar generation details
    "Powerwall2": {
      "enabled": false,
      "serverIP": "192.168.1.2",
  # Password is required starting in firmware 20.49.0
      "password": "test123",
  # The following value specifies the minimum battery level of the
  # Powerwall2 before the car will be able to charge. This avoids a
  # situation where the battery level is low due to low generation, and the
  # battery is then further depleted by the vehicle charging.
      "minBatteryLevel": 90
    },
    "SmartMe": {
      "enabled": false,
      "username": "username",
      "password": "password",
      "serialNumber": "ABC1234"
    },
    "SmartPi": {
      "enabled": false,
      "serverIP": "192.168.1.2",
      "serverPort": "1080"
    },
  # SolarEdge API, consumed from the internet-based SolarEdge Potal
  # or directly from a local inverter with smart meter via modbus TCP
  # NOTE: inverter needs to have modbus TCP enabled - call or email
  #       SolarEdge to enable it for you or use SetApp to enable it
    "SolarEdge": {
      "enabled": false,
  # API Key must be specified in order to monitor a SolarEdge site
      "apiKey": "",
  # Site ID defines which system to monitor
      "siteID": "",
  ## or local inverter, "apiKey" and "siteID" are ignored if you use this
  # local IP address or hostname of inverter
      #"inverterHost": "",
  # default port is 1502, shouldn't need to be changed
      #"inverterPort": 1502,
  # you need 1 smart meter to track consumption, up to 3 are supported
  # NOTE: if a network part is metered by both a consumption and an export
  #       meter, only add one of them or consumption will be counted twice
      #"smartMeters": [{
  # smart meter names currently may be "Meter1", "Meter2", "Meter3"
      #  "name": "Meter1",
  # specify what is metered: "consumption" or "export"
      #  "type": "export"
      #}]
    },
  # SolarLog Inverters
    "SolarLog": {
      "enabled": false,
      "serverIP": "192.168.1.2",
      "excludeConsumptionInverters": [ 2 ] #Array of indices of reading devices - to exclude consumption from. Needed if e.g. a boiler only heats with solar overhead - and you want to override this one.
    },
  # The energy detective
    "TED": {
      "enabled": false,
      "serverIP": "192.168.1.1",
      "serverPort": "80"
    },
  # The openHAB module allows fetching of consumption and generation data from openHAB items.
  # If you do not track one of these values (generation or consumption) via openHAB, leave the parameter blank, and it will not be retrieved.
    "openHAB": {
      "enabled": false,
      "consumptionItem": "Consumption item name",
      "generationItem": "Generation item name",
      "serverIP": "192.168.1.2",
      "serverPort": "8080"
    },
    "Volkszahler": {
      "enabled": false,
      # Yes, you can install TWCManager on same raspi as Volkszäher. (this needs to change "control" > "listenPort" to 8181)
      "serverIP": "127.0.0.1",
      # Port of Volkszahler frontend (not from VZLOGGER).
      "serverPort": "80",
      # Generation in Watt as positive values.
      "uuidPhotovoltaikW": "00000006-0002-1570-ffff-0123456789ab",
      # Consumption from grid as positive values or Push to grid as negative values.
      "uuidTotalGridW": "1cbbe494-a049-11eb-bcbc-0242ac130002"
    },
    # The URL module allows fetching of consumption and generation data from URL items.
    # If you do not track one of these values (generation or consumption) via URL, leave
    # the parameter blank, and it will not be retrieved.
    # Full URLs should use format http[s]://abc/def/[consumptionItemValue|generationItemValue]
    "URL": {
      "enabled": false,
      "url": "http(s)://your/base/url/without/slash/at/end",
      "consumptionItem": "Consumption item name",
      "generationItem": "Generation item name"
    }
  },

# Status plugins allow us to export status detail out of TWCManager.
# This will use interfaces such as MQTT or HomeAssistant API to update status for charging, power draw, etc.
"status": {
    "HASS": {
  # Enabling the HASS status plugin will push TWCManager sensor values to a HomeAssistant server.
        "enabled": true,
        "serverIP": "homeassistant.mydomain.com",
        "serverPort": "443",
        "useHttps": true,

  # Perform rate limiting first (as there are some very chatty topics).
  # For each message that comes through, we take the sensor name and check
  # when we last updated it. If it was less than msgRateInSeconds
  # seconds ago, we send it later.
        "msgRateInSeconds": 10,

  # Resends the last sensor value at least once every resendRateInSeconds,
  # so HASS does not forget the value ;-)
        "resendRateInSeconds": 60,

  # In case of errors, after how many seconds it the logic should try to resend
  # the status
        "retryRateInSeconds": 30,

  # To obtain a HASS API key, via browser, click on your user profile, and
  # add a Long-Lived Access Token. Place it in the following variable:
        "apiKey": "ABC1234"
    },
    "MQTT": {
        "enabled": true,
        "brokerIP": "192.168.21.30",
        "topicPrefix": "TWC",

   # By default we rate-limit per-topic to avoid excessive load on the MQTT server. You are free to reduce the
   # rate limit value as low as you'd like - zero will disable rate limiting altogether. The default is one
   # update per topic every 60 seconds
        "ratelimit": 10,

   # Username and password are optional. If your broker requires a username and password to authenticate
   # clients, set them here. Otherwise, leave them commented out
        "username": "mqttuser",
        "password": "mqttpassword"
    }
},
"vehicle": {
    "TeslaMate": {
        "enabled": true,
        "syncTokens": false,
        "db_host": "192.168.1.1",
        "db_name": "teslamate",
        "db_pass": "teslamate",
        "db_user": "teslamate",
        "syncTelemetry": true,
        "mqtt_host": "192.168.21.30",
        "mqtt_user": "mqttuser",
        "mqtt_pass": "mqttpassword",
        "mqtt_prefix": "teslamate"
    }
}

} `

[cods4]

Any ideas? Or am I simply using this wrong?

@ngardiner @MikeBishop

[MikeBishop]

I vaguely recall a charge a while back to treat negative values as the opposite thing, which might have impacted your setup. But that seems to be exactly what you're doing here, so I'm not sure. How do the logs say it's actually interpreting the values it's getting?

[cods4]

How would I see how it is interpreting the value? I have logging level set to 9. I can see it is getting the negative value, but that seems to be all. The WebUI shows 0W for Generation and Consumption.

I am pretty sure when I was running an earlier version of TWCManager, the negative consumption values got interpreted as excess solar. Not sure if this is a configuration issue on my end, or something has changed in the code.

Logfile:

2023-06-06 10:55:20,925 - HASS 10 getConsumption returns -3035.44 2023-06-06 10:55:20,929 - HASS 10 Generation Entity Not Supplied. Not Querying 2023-06-06 10:55:20,935 - ⛽ Master 10 Number of cars charging now: 0 2023-06-06 10:55:20,939 - ⛽ Master 10 Total amps all slaves are using: 0.0 2023-06-06 10:55:20,945 - 🚗 TeslaAPI 13 Entering car_api_available - next step is to query Tesla API 2023-06-06 10:55:20,950 - 🚗 TeslaAPI 13 car_api_available returning True 2023-06-06 10:55:20,954 - 🚗 TeslaAPI 09 applyChargeLimit return because under 60 sec since last carApiLastChargeLimitApplyTime 2023-06-06 10:55:20,961 - ⛽ Master 10 Total amps all slaves are using: 0.0 2023-06-06 10:55:20,966 - ⛽ Manager 20 Limiting charging to 0.00A - 0.00A = 0.00A. 2023-06-06 10:55:20,971 - ⛽ Manager 20 Charge when above 8A (minAmpsPerTWC). 2023-06-06 10:55:20,977 - 📊 MQTT 10 MQTT Status: Attempting to Connect 2023-06-06 10:55:21,002 - 📊 MQTT 10 Connected to MQTT Broker with RC: 0 2023-06-06 10:55:21,007 - 📊 MQTT 09 Copy Message Buffer 2023-06-06 10:55:21,011 - 📊 MQTT 09 Clear Message Buffer 2023-06-06 10:55:21,015 - 📊 MQTT 13 Publishing MQTT Topic TWC/config/minAmpsPerTWC (value is 8) 2023-06-06 10:55:21,021 - 📊 MQTT 13 Publishing MQTT Topic TWC/all/maxAmpsForSlaves (value is 0)

[cods4]

Any ideas?

This is the only thing that is causing me issues with TWCManager. I have now worked out the scheduler (only works when configured via the HTTP API) and I am able to control everything else via the HTTP API as the MQTT control method was only working intermittently (regularly disconnecting I think).

[cods4]

This is still an issue AFAIK. As a work around I have set up a template sensor in Home Assistant to convert negative power flow into green energy produciton, and a separate sensor for positive power/consumption.