Schneider Electric PowerTag

[OsteHovel]

Information about the device + link

Schneider Electric PowerTag Monoconnect 63A 1P+N top position

This is energy sensor utilizing Zigbee 3 Green Power

https://www.se.com/ww/en/product/A9MEM1521/energy-sensor%2C-powertag-monoconnect-63a-1p%2Bn-top-position/

data/database.db entry of the device

This gets added during pairing, but it actually does not really pair completely more info below

{
  "id": 3,
  "type": "GreenPower",
  "ieeeAddr": "0x00000000e20765cb",
  "nwkAddr": 26059,
  "manufId": null,
  "modelId": "GreenPower_254",
  "epList": [
    242
  ],
  "endpoints": {
    "242": {
      "epId": 242,
      "inClusterList": [],
      "outClusterList": [],
      "clusters": {},
      "binds": [],
      "configuredReportings": [],
      "meta": {}
    }
  },
  "interviewCompleted": true,
  "meta": {},
  "lastSeen": 1625428765211
}

Info	Info
OS	Windows
Zigbee2mqtt	Latest on master branch
Zigbee-herdsman	Latest on master branch
Cordinator	CC2531
Channel	15
Network key	0c9f45818f14a953d0993f2304015e10

I have tried with both using a Philips Hue Light strip and using a IKEA E1746 TRADFRI signal repeater

Utilizing the Philips Hue Light strip the light strip does not reply to the channel request sent out by the PowerTag. By utilizing a IKEA signal repeater that actually replies to the channel requests and gets it on the correct channel and sending out a commissioning notification, see Channel request and configuration.pcapng.

I had to do some changes to Zigbee-herdsman to get it actually decode the packet correctly buffaloZcl.ts - Added a check for key present during payload

private readGdpFrame(options: TsType.Options): Gdp | {raw: Buffer} | Record<string, never> {
    // Commisioning
    if (options.payload.commandID === 224) {
        const deviceID = this.readUInt8();
        const options1 = this.readUInt8();
        const extendedOptions = this.readUInt8();

        const gdpKeyPresent = (extendedOptions & 0x20) != 0;
        if (gdpKeyPresent) {
            return {
                deviceID: deviceID,
                options: options1,
                extendedOptions: extendedOptions,
                securityKey: this.readBuffer(16),
                keyMic: this.readUInt32(),
                outgoingCounter: this.readUInt32(),
            };
        } else {
            return {
                deviceID: deviceID,
                options: options1,
                extendedOptions: extendedOptions,
                securityKey: null,
                keyMic: null,
                outgoingCounter: this.readUInt32(),
            };
        }
    } else if (this.position != this.buffer.length) {
        return {raw: this.buffer.slice(this.position)};
    } else {
        return {};
    }
}

greenPower.ts

public async onZclGreenPowerData(dataPayload: AdapterEvents.ZclDataPayload): Promise<void> {
    if (dataPayload.frame.Payload.commandID === 224 && typeof dataPayload.address === 'number') {

        const keyPresent = (dataPayload.frame.Payload.extendedOptions & 0x20) != 0;
        if (keyPresent) {
            const key = this.encryptSecurityKey(
                dataPayload.frame.Payload.srcID, dataPayload.frame.Payload.commandFrame.securityKey
            );

            const payload = {
                options: 0b1_1_100_10_1_0_10_0_1_000,
                srcID: dataPayload.frame.Payload.srcID,
                sinkGroupID: this.adapter.greenPowerGroup,
                deviceID: dataPayload.frame.Payload.commandFrame.deviceID,
                frameCounter: dataPayload.frame.Payload.commandFrame.outgoingCounter,
                gpdKey: [...key],
            };

            const frame = Zcl.ZclFrame.create(
                Zcl.FrameType.SPECIFIC, Zcl.Direction.SERVER_TO_CLIENT, true,
                null, ZclTransactionSequenceNumber.next(), 'pairing', 33, payload
            );

            await this.adapter.sendZclFrameToAll(242, frame, 242);
        } else {
            // Key not present security
            const key = Buffer.from([0xc9, 0x79, 0xd5, 0x22, 0x9c, 0xb9, 0xe9,
                0xd2, 0x8d, 0x5d, 0xa6, 0x99, 0xf8, 0xca, 0x02, 0x97]);

            const options = 0b1_1_010_11_1_1_10_0_1_000;
            const payload = {
                options: options,
                srcID: dataPayload.frame.Payload.srcID,
                sinkGroupID: this.adapter.greenPowerGroup,
                deviceID: dataPayload.frame.Payload.commandFrame.deviceID,
                frameCounter: dataPayload.frame.Payload.commandFrame.outgoingCounter,
                gpdKey: [...key],
            };

            const frame = Zcl.ZclFrame.create(
                Zcl.FrameType.SPECIFIC, Zcl.Direction.SERVER_TO_CLIENT, true,
                null, ZclTransactionSequenceNumber.next(), 'pairing', 33, payload
            );

            await this.adapter.sendZclFrameToAll(242, frame, 242);
        }

        const eventData: GreenPowerDeviceJoinedPayload = {
            sourceID: dataPayload.frame.Payload.srcID,
            deviceID: dataPayload.frame.Payload.commandFrame.deviceID,
            networkAddress: dataPayload.address,
        };

        this.emit(GreenPowerEvents.deviceJoined, eventData);
    }
}

I have flipped around with the options to try to get any response.

PowerTag Commissioning.pcapng is a captured when the PowerTag is being commissioned by a Schnieder Electric Acti 9 Smartlink SI B

Zigbee2mqtt pairing.pcapng is a capture of what happening when I am trying to pair with zigbee2mqtt I am thinking it is because the IKEA Signal Repeater (and for that matter the Philips Hue) is repeating the Green Power using protocol version 2 instead of 3, or I am just formatting the packets wrong.

[OsteHovel]

I realized when I read this post again that I should include some screen captures so people do not need to click the links and download the capture files to see what I am talking about

So the PowerTag send out this Commission packet after getting the Channel Configuration

Using Acti 9 Smartlink SI B

Then using Acti 9 Smartlink SI B it will reply Commission Reply

And then the device replies Success and everyone is happy

Using Zigbee2mqtt

Using zigbee2mqtt the Commission packet from the PowerTag gets translated/packet into a Zigbee packet:

And I try to reply to that packet:

And nothing happens, it just continuing to send out Commission packet like nothing happened. It kind of make sense to me as I cannot see any packet getting translated to Green Power and sent out by the proxy(Signal Repeater or Hue light strip) Its like it is just ignored

[NicolaiPetri]

I will follow here. I have the almost same devices, just 3p+0 model and I tried adding a Hue White bulb to my network but I get absolutely no pairing from the device. I'm using latest release from July 1st. Do I need to upgrade to latest unstable version ? Or what can I do to get at least pairing to work ? I don't mind testing stuff if you need it. UPDATE After adding an IKEA repeater I now see this in my log: Zigbee2MQTT:debug 2021-07-08 16:48:14: Received Zigbee message from '0x000d6ffffe903cb6', type 'raw', cluster 'greenPower', data '{"data":[9,60,6,8,117,30,9,0,0,0,0,243,1,29],"type":"Buffer"}' from endpoint 242 with groupID 0 Zigbee2MQTT:debug 2021-07-08 16:48:14: No converter available for 'E1746' with cluster 'greenPower' and type 'raw' and data '{"data":[9,60,6,8,117,30,9,0,0,0,0,243,1,29],"type":"Buffer"}'

[NicolaiPetri]

After enabling further debugging this is also present in the logs (snippet), I'm not sure it's related but endpoint 242 seems to be right:

Zigbee2MQTT:debug 2021-07-08 17:51:21: Received Zigbee message from 'Repeater1', type 'raw', cluster 'greenPower', data '{"data":[9,73,6,8,117,30,14,0,0,0,0,243,1,29],"type":"Buffer"}' from endpoint 242 with groupID 0 zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,39,68,129,0,0,33,0,7,0,242,242,1,60,0,8,12,202,0,0,19,17,72,4,8,8,0,0,0,0,87,0,0,0,227,1,94,117,30,207,117,30,29,64] +8ms zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 39 - 2 - 4 - 129 - [0,0,33,0,7,0,242,242,1,60,0,8,12,202,0,0,19,17,72,4,8,8,0,0,0,0,87,0,0,0,227,1,94,117,30,207,117,30,29] - 64 +12ms zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":33,"srcaddr":7,"srcendpoint":242,"dstendpoint":242,"wasbroadcast":1,"linkquality":60,"securityuse":0,"timestamp":13241352,"transseqnumber":0,"len":19,"data":{"type":"Buffer","data":[17,72,4,8,8,0,0,0,0,87,0,0,0,227,1,94,117,30,207]}} +23ms zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":72,"manufacturerCode":null,"commandIdentifier":4},"Payload":{"options":2056,"srcID":0,"frameCounter":87,"commandID":227,"payloadSize":1,"commandFrame":{"raw":{"type":"Buffer","data":[94,117,30,207]}}},"Command":{"ID":4,"parameters":[{"name":"options","type":33},{"name":"srcID","type":35},{"name":"frameCounter","type":35},{"name":"commandID","type":32},{"name":"payloadSize","type":32},{"name":"commandFrame","type":1009}],"name":"commisioningNotification"}},"address":7,"endpoint":242,"linkquality":60,"groupID":0,"wasBroadcast":true,"destinationEndpoint":242}' +25ms zigbee-herdsman:controller:log 'zcl' data is from unknown device with address '7', skipping... +13ms zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [] +24ms Zigbee2MQTT:debug 2021-07-08 17:51:21: No converter available for 'E1746' with cluster 'greenPower' and type 'raw' and data '{"data":[9,73,6,8,117,30,14,0,0,0,0,243,1,29],"type":"Buffer"}' zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,50,68,129,0,0,33,0,121,11,242,242,1,60,0,7,50,203,0,0,30,17,74,4,8,8,121,11,2,226,93,0] +1s zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,50,68,129,0,0,33,0,121,11,242,242,1,60,0,7,50,203,0,0,30,17,74,4,8,8,121,11,2,226,93,0] +1ms zigbee-herdsman:adapter:zStack:unpi:parser <-- [0,0,224,12,254,231,131,121,18,0,0,3,94,16,93,67,117,30,208,117,30,29,106] +21ms zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,50,68,129,0,0,33,0,121,11,242,242,1,60,0,7,50,203,0,0,30,17,74,4,8,8,121,11,2,226,93,0,0,0,224,12,254,231,131,121,18,0,0,3,94,16,93,67,117,30,208,117,30,29,106] +0ms zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 50 - 2 - 4 - 129 - [0,0,33,0,121,11,242,242,1,60,0,7,50,203,0,0,30,17,74,4,8,8,121,11,2,226,93,0,0,0,224,12,254,231,131,121,18,0,0,3,94,16,93,67,117,30,208,117,30,29] - 106 +1ms zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":33,"srcaddr":2937,"srcendpoint":242,"dstendpoint":242,"wasbroadcast":1,"linkquality":60,"securityuse":0,"timestamp":13316615,"transseqnumber":0,"len":30,"data":{"type":"Buffer","data":[17,74,4,8,8,121,11,2,226,93,0,0,0,224,12,254,231,131,121,18,0,0,3,94,16,93,67,117,30,208]}} +1s zigbee-herdsman:controller:log Received 'raw' data '{"clusterID":33,"data":{"type":"Buffer","data":[17,74,4,8,8,121,11,2,226,93,0,0,0,224,12,254,231,131,121,18,0,0,3,94,16,93,67,117,30,208]},"address":2937,"endpoint":242,"linkquality":60,"groupID":0,"wasBroadcast":true,"destinationEndpoint":242}' +1s zigbee-herdsman:controller:log 'raw' data is from unknown device with address '2937', skipping... +1ms

[rindlerblabla]

Any updates on this? Don't have those devices but would be interested in getting them.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[rindlerblabla]

I am still interested in thise devices but don't have any myself...

[OsteHovel]

I ended up purchasing the gateway from Schneider Electric, but it would still be nice to be able to add to them to Zigbee2mqtt. I am at a standstill on what to do or what I can test to make it work. I have 10 of them

[rindlerblabla]

Cool! That's beyond my knowledge, but have you tried sniffing the network when you connect the power tag to the Schneider gateway?

[OsteHovel]

Cool! That's beyond my knowledge, but have you tried sniffing the network when you connect the power tag to the Schneider gateway?

Yepp, I actually borrowed a gateway before I purchased it, to try to avoid using the gateway at all. The network capture is linked on the bottom of the first post else you find it here

[rindlerblabla]

Do you think it would do any difference if you paired it through some other green power supported device?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[OsteHovel]

I did try with both a Philips Hue Light Strip and a Ikea Signal Repeater.

[rindlerblabla]

Sorry for tagging, but @sjorge or @Koenkk could you help out in some way how to pair these green power sensors? Guess that most info is in the second post in this thread.

[sjorge]

Sorry for tagging, but @sjorge or @Koenkk could you help out in some way how to pair these green power sensors? Guess that most info is in the second post in this thread.

Best wait for Koen, I have no experience with GP devices. A bit surprising an energy meter is using GP too. I'd have not expected that as GP is rather limited, but that is mostly because they are supposed to harvest energy from the user actuating the buttons, at least how I understood it.

[Koenkk]

Can you check wether this device can be paired to a Hue bridge?

[filips]

I managed to get some progress on pairing the Schneider PowerTag devices.

I am still working on cleaning up the code I have, but the main element necessary to complete the pairing is implementing the GP Commisioning Reply (0xF0) command. We probably also need to respond to the GP Channel Request (0xE3). Currently I had an IKEA Float lamp sporadically shouting out "Channel 16" to the device, which is not at all what I'm using, so need to figure out how to get that one to be quiet during commisioning.

Here you see what I'm sniffing after the commisioning flow done by zigbee2mqtt:

I still need to fix up the GP Pairing request to make the GPP forward the GP frames to me, but that should be relatively simple.

[LET-Felix]

@filips Any update on pairing powertag devices to zigbee2mqtt?

[Twiistz]

Any update on this?

[smulle48]

Any news?

[Inrego]

@filips would you mind sharing what you have so far? It seems you didn't have the time/interest to finish it up, so if you post what you got so far, maybe someone else could pick up and continue.

[filips]

I'm sorry, been really busy with work lately. My current WIP code is very rough and hard-coded, so I don't know it will serve much purpose sharing it, but I will gladly elaborate on my findings.

Essentially what needs to be done is the specific handling of more Green Power commands. Currently in greenPower.ts in onZclGreenPowerData only the GP Commissioning command is handled.

This works for some very simple Green Power devices, where you simply need to send a pairing packet to a GP Proxy, instructing it to forward the one-way data. For an RX enabled device like Schneider PowerTag, the flow is somewhat more complicated.

The commands that need responses are, to my understanding, these:

switch(dataPayload.frame.Payload.commandID) {
    case undefined:
        // GP Undefined Command
        break;
    case 0xE0:
        // GP Commissioning
        // You (Sink) should respond with GP Commissioning Reply
        break
    case 0xE2:
        // GP Success
        // You should send a pairing command to set up GP Proxy to forward messages
        break;
    case 0xE3:
        // GP Channel Request
        // You should reply with a GP Channel Reply 
        break
    case 0xA1:
        // GP Manufacturer-specific Attribute Reporting
        // This is the actual data received
        break;
    default:
        // Unhandled GP Command
}

So in this case, the flow will be something like this:

• GP Device sends GP Channel Request to get Zigbee chanel
• GP Sink (you) send a GP Channel Reply to let the GP Device know which channel is used
• GP Device sends GP Commissioning
• GP Sink (you) send GP Commissioning Reply, instructing GP Device of all settings
• GP Device will send GP Success if successful
• GP Sink (you) will now send a pairing packet, configuring GP Proxy to mediate the data sent from GP Device over the Zigbee Network

[Inrego]

I recently started getting problems with wiser2mqtt, unable to authenticate to it. So I'm back to hoping for progress on this. @Koenkk can this issue be reopened? I'm not sure why it was closed in the first case.

[Inrego]

Hmm.. Even though these powertags are paired to their own bridge, they are still joining my Z2M network and spamming unsupported messages: Even though I remove it and block it from re-joining, it somehow joins again after a little while. While joined, it's spamming errors in the Z2M log about every second.

So all in all, looking forward to having these devices properly joined on my Z2M network instead :)

[Inrego]

https://zigbeealliance.org/wp-content/uploads/2019/11/docs-09-5499-26-batt-zigbee-green-power-specification.pdf

Here's the link to the GP specification. In case it's needed by anyone who didn't find it already. I currently run Z2M in docker, so I'm not sure if/how I could go about setting up a developing/testing environment. I don't have extra zigbee coordinators, and I don't want to mess up my current zigbee network with 100+ devices in it.

Also I don't have much knowledge on the technical side of Zigbee, but that wouldn't hold me back from getting into it, as that's just something I can learn :)

But I am still rooting for @filips

Especially with the recent update to the original powertag bridge, which prevents us from automating gathering data directly from that.

[filips]

I have had some progress with the PowerTags.

One slightly odd thing is that Schneider has implemented a form of ACK'ing for received Manufacturer-specific Attribute Reports. If this ACK is not sent, one will only see some boring model number reports - not the actual readings.

Just moments ago I got everything plumbed through, and got this reading in the Z2M web UI:

There are a number of outstanding items still remaining, including:

• Cleanup of hardcoded options fields/command structures/etc.
• Investigation into using encrypted connection between GP Proxy and the powertags. In my initial attempts I did not manage to pair the GP Device to a GP Proxy in a way that allowed GP Response packets (in this case the strange ACK) to be encrypted by the proxy before sending it to the powertag.
• Implementation of remaining reported values

I'm not quite sure where it would make most sense to put the code that sends the manufacturer specific ACK frame out.. Right now I just have it in greenPower.ts, but that's definitely not right.

[Inrego]

Maybe @Koenkk can weigh in on how to structure the code?

[smulle48]

I'm looking forward for the development, as I'm planing to buy one for my BEV Charger 😁

[Koenkk]

@filips where did you get stuck?

[smulle48]

This one looks quite interesting.

Is says Harmony Hub in the description. Maybe that will connect easier

[LET-Felix]

Harmony Hub is also made by schneider electric and afaik all powertag devices work with it (never tried it though)

[smulle48]

Harmony Hub is also made by schneider electric and afaik all powertag devices work with it (never tried it though)

It only says Harmony Hub for the models with cable :-)

[LET-Felix]

Thats interesting, any idea what’s different about those? At least from the outside I cannot see any difference.

[smulle48]

Thats interesting, any idea what’s different about those? At least from the outside I cannot see any difference.

I have no idea, but I'll try to order one :-)

[filips]

The PowerTag with the external power connections is the one I have been using for development. AFAIK nothing is different between that one and the models with built-in contacts.

Having it externally powered can make sense for development purposes, as toggling power after communication times out is the way to initiate the commissioning flow.

[smulle48]

The PowerTag with the external power connections is the one I have been using for development. AFAIK nothing is different between that one and the models with built-in contacts.

Having it externally powered can make sense for development purposes, as toggling power after communication times out is the way to initiate the commissioning flow.

Just found out that Harmony Hub referees to Schneider's own data hub called Harmony Hub 😁

[verydrunk]

R9 is for the residential user, A9 (Acti9) is for industrial and commercial buildings and is mostly used with modbus tcp ip for that buildings "superior control system" (is it the right English word for it?)

[filips]

Support has been merged to dev, feel free to try it out if you get a chance :)

[smulle48]

Looking forward to testing it :-)

[NicolaiPetri]

Do anyone know how to re-pair a device that is already connected to a Scheider gateway ?

[verydrunk]

I guess u go in eSetup and remove it from the gateway to release it

[filips]

Either that, or you can turn off the gateway and wait until the led on the powertag blinks quickly red (~2 times per second). Then power cycling the powertag initiates commissioning

[smulle48]

@filips is there a specific way the power has to run through the powertag? Can't see any direction markings on it

[filips]

@filips is there a specific way the power has to run through the powertag? Can't see any direction markings on it

I don't believe so, as long as N and the phases are connected correctly.

[smulle48]

@filips is there a specific way the power has to run through the powertag? Can't see any direction markings on it

I don't believe so, as long as N and the phases are connected correctly.

I found out it has to go from "top to bottom"

Btw. how often does it report? and is there a way (as for now) to change that time?

[filips]

Ah ok, that's also the way I have mine wired.

It reports around every five seconds by default. I've seen some GP Write Attribute commands from the wiser gateway that may configure this, but it is not something I've looked into.

[filips]

By the way, this is the command i suspect could have something to do with the reporting interval:

[avsantos76]

Maybe this could help in the solution, after all the diference is the number o phases that each device can support: https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/A9MEM1570.md

[edenhome]

I have been testing Powertag with direct link to zigbee2mqtt, model R9M70 works perfect, model R9M41links but don’t show any values

[smulle48]

I have been testing Powertag with direct link to zigbee2mqtt, model R9M70 works perfect, model R9M41links but don’t show any values

Try to post your debug log when adding it to the network. Maybe we can figure out something to make it work 😃

[edenhome]

I assume this it what you mean,, I very unfamiliar with zigbee2mqtt