Add some news field for future DDF (Consumption/power device)

[Smanar]

Not used yet, but add

• Current phase 1
• Curent phase 2
• Current phase 3
• A second consumption
• A production counter.

[manup]

I'm not sure about state/consumption_2 and state/production and their meaning, is there a specific device which requires these?

[Smanar]

state/production for all devices that mesure consumption and production.
And yes, we are on the DDF ATM, it's a device used for the whole house, so users with solar panel have production too.
The attribute 0x0001 is for production (not consumption)

				<attribute id="0x0000" name="Current Summation Delivered" type="u48" access="r" required="m"></attribute>
				<attribute id="0x0001" name="Current Summation Received" type="u48" access="r" required="o"></attribute>

state/consumption_2
I m trying to be generic for this one, but yes the same device than before mesure consumption during 2 period (not the same price), so the device have 2 counters ( or more)
I can use period name, but will need for exemple state/consumptionHC and state/consumptionHP and can't be used for other usage.

[manup]

Cool, thanks that's indeed useful data to have 👍

[ebaauw]

I agree it’s useful to add attributes for these, but I’d urge to reconsider the naming and API design. I don’t know about Zigbee power meters, but in the DSMR standard they support consumption vs delivery attributes for not just consumption, but also power and current. Also the attributes in the Simple Metering cluster talk about delivered vs received. I would really prefer consumption (even consumption_received) vs consumption_delivered instead of production. Also I light of future power_delivered and current_delivered.

For three-phase electricity it’s probably best to use a subobject per phase, allowing for power, current, and voltage per phase. DSMR doesn’t define a consumption per phase, though. It does allow for different rates (e.g. day vs night rates), both for consumption delivered and received.

[Smanar]

It's not a problem for me, I can use state/consumption and state/consumption_delivered time for third app support state/consumption_received.

Can do a new PR, I will adapt my future DDF for consuption, and can keep state/consumption and state/consumption_delivered for compatiblity with third app.

For the Tree phase, do you have a json exemple ? IDK if it s better to make something for future or try to keep the compatibilities with third app ...

[ebaauw]

Don't really have an example for any Zigbee device, but here is how I parse the DSMR telegram into JSON:

{
  "type": "ISK5\\2M550T-1012",
  "version": "5.0",
  "msg_text": "",
  "electricity": {
    "id": "E0044007118529318",
    "lastupdated": "2019-12-29T23:37:14",
    "tariff": "low",
    "consumption": {
      "low": 4000.647,
      "normal": 1154.948
    },
    "power": 1765,
    "failures": {
      "short": 9,
      "long": 4,
      "log": {
        "2018-03-27T06:41:11": 180,
        "2019-01-08T10:59:23": 2603
      }
    },
    "l1": {
      "voltage": 236.9,
      "sags": 1,
      "swells": 1,
      "current": 0,
      "power": 132
    },
    "l2": {
      "voltage": 235.1,
      "sags": 1,
      "swells": 1,
      "current": 0,
      "power": 37
    },
    "l3": {
      "voltage": 234.9,
      "sags": 1,
      "swells": 1,
      "current": 6,
      "power": 1596
    }
  },
  "electricityBack": {
    "id": "E0044007118529318B",
    "lastupdated": "2019-12-29T23:37:14",
    "tariff": "low",
    "consumption": {
      "low": 0,
      "normal": 0
    },
    "power": 0,
    "l1": {
      "power": 0
    },
    "l2": {
      "power": 0
    },
    "l3": {
      "power": 0
    }
  }
}

[Smanar]

So you want to use array in the JSON ? or dictionary ?

[ebaauw]

That seems cleaner than repeated attributes with a changing suffix. Don't think we use that much today. Really need to do a proper design of the API going forward.