Single node 'gpu_hist' is not reproducible

XGBoost model is still not reproducible on single device with tree_method = 'gpu_hist'. If the DMatrix is loaded into the single gpu device, the model is replicated in the sense that every time you train the model, the result will be the same because the DMatrix is cached in the device as I observed. However, if you use another device, or load DMatrix again, the model will be slightly different from the previous one.

or load DMatrix again

Hi, could you please share an example script that the training is not reproducible?

@trivialfis Thanks for the quick response. Sorry, I can't share the data and don't have the method to generate such data. It does not always happen because on some data I can 100% replicate my result, so I think it may be due to a special case on some features.
The following is my sample code and observation (result is not real but for demonstration purpose). Although the auc is very close, but they are not exactly the same.
xgboost version :1.4.2
params = {'eta':0.05, 'max_depth':6, 'alpha':50.0, 'lambda':10.0, 'objective':'binary:logistic', 'eval_metric':'auc',
'tree_method':'gpu_hist'
}
for gpu_id in [0,1,2,3]:
params.update({'gpu_id':gpu_id})
xgbmodel = xgb.train{params, xgb.DMatrix(train_data, label = y), 1000)
y_pred = xgbmodel.predict(xgb.DMatrix(train_data))
auc = roc_auc_score(y, y_pred)
print(gpu_id, auc)

0 0.62433
1  0.62427
2 0.62437
3 0.62396
I will try to test some other simulated data to see if I can produce similar issue. I will update it once I have it.

Feel free to open a new issue if you have a reproducible example.


Crash Report w/ Lunatruis Core & Schematica

Mod version: --LunatriusCore-1.11-<IP_ADDRESS>-universal-- & ---Schematica-1.11-<IP_ADDRESS>-universal ---
Forge version: --forge-<IP_ADDRESS>6--
Operating system: --windows 10--
Mod list:

Crash report: --- ---
#1 Then trying to create / launch a single player world:
*: crash-2017-05-12_23.05.44-server.txt
The latest logs
*:  logs zip.zip
#2 loading into a single player world / multi player server, read comments below *
The crash log:
*: crash-2017-05-12_23.44.03-client.txt
The latest log:
*:  latest logs.zip
Extra info & things to say

#1 It seems then using this mod set , then i am trying to make / load up a single player world i get stuck on loading world & having to ctrl-alt-del and close the game with task manger.
#2 Then trying to join a server that is vanilla and or bukkit plugin server ( witch does allow this mod to work since iv seen other people use it right ) it seems to let me log in for about 2-4 sec to be able to see chat and where i am standing then crash me back to the launcher.
#3 My thought of mods that could be causing the crash would be waila , inventory tweaks and or opti define since it seems they been having a bit of problems with latest versions.

Update yep optidefine is broken as shit but still may want to look in to this. dam now i need to bug report opidefine great times ...

Closing this as a non issue if it's Optifine. If it's not, feel free to re-open the ticket.


[Vue] v-model not working on  tag

Hi,
I'm using the latest Ionic beta with Vue.js and I have noticed that if I use:
<ion-input v-model="msg" />

This is not working at all... the v-model attribute is not set on ion-input and its input element.
What do you advise me to work around that?
Thanks,
PS: It's also related to #14912

👋 Hi, this is a known limitation in Vue. For custom input component, you need to bind to different events in order to mimic v-model. For example, in an app that uses searchbar, you to use ionInput instead
        <ion-searchbar
          placeholder=""
          showCancelButton="true"
          debounce="0"
          :value="searchInput"
          @ionInput="searchInput = $event.target.value; onInput$.next($event.target.value)"
          @ionClear="searchCleared($event)">
        </ion-searchbar>

This isn't needed in Angular as it has the idea of Control Value Accessors which can enable ngModel support. I don't think Vue has anything similar, so this might be needed until we work on a proper vue integration layer and investigate things


Add ability to add User Input (Choice) powered by LUIS intents

Is your feature request related to a problem? Please describe.
As a user, I would like to be able to provide a User Input (Choice) powered by LUIS, so that I can use the power of LUIS to catch intents to do things like confirmations natively in composer.
Describe the solution you'd like
When creating a User Input (Choice) being able to select an intent as an option in the choice matrix.
Additional context
Use the Synonyms option to allow selection of LUIS intent:

Other options may be other choices that may have multiple ways of saying the same thing. Example:
How would you like to get notified:
Choice Prompt: (Text / Email / None)

Support of "Send it to me in mail" = Email
Support of "SMS works for me" = Text
Support of "I don't want to get any notifications please." = None

By supporting this mechanism, a user could define the intent selections once and not have to manage the details of synonyms in ever dialog, but just reuse them and update training as necessary without having to touch every place in the dialog where that Choice is defined.

@cwhitten I'd like to implement this exact behaviour as well but I see that this ticket got closed without any comment. Is there already a way to do this?

Hi @tobias-correia. No, this request was not implemented. We have no plans to prioritize supporting this scenario.

Hi @cwhitten I would also appreciate that feature. But closing doesn't mean not to prioritize, it means not to support it at all, as I understand.
In a real-life-bot-scenario with LUIS (in our case, it's a recruiting bot) this is a must-have feature as users won't answer just with the given options the control is expecting. I built a quite ugly workaround for this, but it would be much better to at least be able to relate the options with intents.


python setup.py develop does not work

python setup.py develop does not work out of the box with Python-2.7.x and Lancet.

I will look into this shortly!
I would just note that for development, I don't use setup.py develop myself and would probably recommend  cloning the git repository instead. For instance, we would be happy to accept proposed improvements to Lancet via pull requests (i.e we recommend that you fork the Lancet git repository, make some changes and then submit a pull request).
That said, because I don't use this command myself it is possible I don't understand your use-case properly. What is it you would you like to use setup.py developfor?
Regardless, I will try to fix this issue if I can!

I hadn't noticed your PR. I assume you have tested it and therefore I am happy to merge it right away if you wish!


Connect bridge CLI to clients

Description
The CLI for the bridge can be found here https://github.com/movementlabsxyz/movement/blob/08d044172f05fcde5c83cd3fd0a1c9594d35290d/protocol-units/bridge/cli/src/clap.rs
It doesn't yet make calls to the Client. Calls should happen via RPC requests.
Requirements

Update Clients with any necessary RPC parse code.
Connect the CLI to the Client.
Write integration tests for the CLI calls

Points: 3

Hi! I have several questions regarding the integration of the CLI with the Client for the bridge:

Client Interaction: What specific functionalities of the Client should the CLI interact with? Are there any existing examples or documentation that can guide this integration?

RPC Endpoint Configuration: If calls are supposed to happen via RPC requests, where are the RPC endpoints configured? Is there a specific service where the RPC endpoint definitions can be found?

Bridge Client Methods: Are the bridge client methods exposed via RPC? If so, where can we find examples/documentation of these calls?


[test] Add tests for async_close

This closes #571

I've updated the commit message. I believe there were no open issues for this PR.


How to access outside

After I allocate the IP address to the docker container. I could only able to ping the IP only on base machine. I want this IP to ping outside of my base machine.
The IP I added are routeble.
[root@Docker-Calico ~]# calicoctl pool show
+-------------+---------+
|  IPv4 CIDR  | Options |
+-------------+---------+
| <IP_ADDRESS>/24 |         |
+-------------+---------+
calicoctl container add workload-A <IP_ADDRESS>
[root@Docker-Calico ~]# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.048 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.045 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=0.060 ms
[root@Docker-Calico ~]# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.048 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.045 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=0.060 ms
If I try to ping outside the base machine I could not able to ping the container with ip.

@sjkeerthi what type of network are you running Calico over?  Is it a layer 2 or layer 3 network?
If it's a layer 3 network, have you peered the Calico hosts with your BGP routers in the network?

Closing due to lack of activity.


storage: Writer always truncates files on close

Reference: https://github.com/GoogleCloudPlatform/gcloud-golang/pull/218
Quoted from GoDoc's ObjectHandle.NewWriter:

NewWriter returns a storage Writer that writes to the GCS object associated with this ObjectHandle. If such an object doesn't exist, it creates one. Attributes can be set on the object by modifying the returned Writer's ObjectAttrs field before the first call to Write.

It is the caller's responsibility to call Close when writing is done.

The object is not available and any previous object with the same name is not replaced on Cloud Storage until Close is called.

I propose adding a brief explanation of what happens when objects do already exist as there's no way, that I'm aware of, for opening a file for writing without truncating it.
/cc @bradfitz

GCS is not a POSIX filesystem. It's true you can't do random writes inside objects, nor open an object for read+write.
We can probably add a bit more text.

It actually is explained rather well at https://cloud.google.com/storage/docs/key-terms on bullet point "Object immutability" and inter-operation behavior at https://cloud.google.com/storage/docs/consistency so linking to this might suffice.


Implements negation.

Implements pixel-wise negation.
One caveat -- this negates all bands, including alpha.  Not sure if thats "right" or desirable, but it is at least symmetric.

Marvellous, thanks again David.


[5.5] Convert all responses to Illuminate Response

This PR ensures that all response objects passed to middleware is an instance of Illuminate\Http\Response.

can you explain the though process behind this?

@browner12 trying to unify the response object passed to middleware, currently you may receive an Illuminate Response or a Symfony Response, this PR ensures you always get an Illuminate Response.

Potential breaking changes would be it's no longer possible to use JsonResponse methods in your middleware.

that's kind of what I was curious about.

We may want to make this return either Illuminate\Http\Response or Illuminate\Http\JsonResponse. I'm afraid it will be too breaking and limiting to prevent JsonResponse returns.
Another alternative would be to stop extending Symfony JsonResponse entirely, copy its one or two methods over into our own JsonResponse, and then make our JsonResponse extend Illuminate Response.  This would unify them more. Thoughts?

Going to close this for now while it's in progress just to keep my PR list tidy.


Cannot read property 'toLowerCase' of undefined

I am trying to use vue-tel-input within nuxtjs and keep getting the exception above, when having a predefined value.
          <vue-tel-input
            v-model="phone"
            name="Telefonnummer"
            type="text"
            :disabled-fetching-country="true"
            placeholder="Telefonnummer eintragen"
            :only-countries="['DE']"
          />

When defining an empty value in the components state, it works fine:
export default class CustomerAddressesForm extends Vue {
    phone: string = ''
}

However, when predefining the value, I get the exception Cannot read property 'toLowerCase' of undefined
export default class CustomerAddressesForm extends Vue {
    phone: string = '1234'
}

When disabling flags :enabled-flags="false", it does work.

What version are you using? Are you able to reproduce in the Codesanbox (using our latest version)?
I have been trying in dev but no luck to get the error.

@iamstevendao I am using the latest version of vue-tel-input within the latest version of Nuxt.js. I will try to provide a sample asap

I am unable to reproduce this myself, so I am going to close this for now.


cdc: enhance async scan metrics and log

What problem does this PR solve?
Enhance some CDC metrics and log.
Related changes

Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test

Release note

No release note.

/lgtm


Please add NSAppleMusicUsageDescription

Feature Request:
Please fill in what you would like
I'm trying to access the iPOD library with MPMediaQuery this requires in pInfo but I think I have to request it also from the App because my App is not halted while the OS asks for the permission and therefore crashes.
Unfortunately this permission is not yet implemented in the plugin.
Would be great if you could add it.
Best
THomas

Just added a PR https://github.com/jamesmontemagno/PermissionsPlugin/pull/26
for it.
I didn't know if I have to add something to the Android implementation as it seems on Android  no additonal Permissions are needed to access the Medialibrary.
I don't know how it is handled on UWP.
Cheers
Thomas


drivers: spi: nRF SPI add control of MISO pin pull

Allow change of the MISO pin pull in SPI/SPIM.
Signed-off-by: Pawel Dunaj<EMAIL_ADDRESS>

Codecov Report

Merging #13950 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #13950      +/-   ##
==========================================
- Coverage   52.29%   52.29%   -0.01%
==========================================
  Files         307      307
  Lines       45429    45429
  Branches    10506    10506
==========================================
- Hits        23756    23755       -1
  Misses      16887    16887
- Partials     4786     4787       +1

Impacted Files
Coverage Δ

arch/posix/core/posix_core.c
90.9% <0%> (-1.02%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e731bdc...340ffa2. Read the comment docs.

Hi @carlescufi , could you merge?


[Device Support Request] _TZE204_81yrt3lo TS0601 Zigbee power meter with clamp

Problem description
The device is discovered, but with no sensors. I have all connected fine, I can see total and instantaneous power in Tuya app. Where to start?
Solution description
Any
Screenshots/Video
Screenshots/Video
[Paste/upload your media here]

Device signature
Device signature
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Coordinator: 0>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice|AlternatePanCoordinator: 143>, manufacturer_code=43981, maximum_buffer_size=82, maximum_incoming_transfer_size=128, server_mask=11329, maximum_outgoing_transfer_size=128, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=True, *is_coordinator=True, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": "0x0104",
      "device_type": "0x0400",
      "input_clusters": [
        "0x0000",
        "0x0006",
        "0x000a",
        "0x0019",
        "0x0501"
      ],
      "output_clusters": [
        "0x0001",
        "0x0020",
        "0x0500",
        "0x0502"
      ]
    }
  },
  "manufacturer": "Silicon Labs",
  "model": "EZSP",
  "class": "zigpy.device.Device"
}

Diagnostic information
Diagnostic information
{
  "home_assistant": {
    "installation_type": "Home Assistant Supervised",
    "version": "2023.5.4",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.10.11",
    "docker": true,
    "arch": "armv7l",
    "timezone": "Europe/Madrid",
    "os_name": "Linux",
    "os_version": "5.10.103-v7l+",
    "supervisor": "2023.08.1",
    "host_os": "Raspbian GNU/Linux 10 (buster)",
    "docker_version": "20.10.14",
    "chassis": "",
    "run_as_root": true
  },
  "custom_components": {
    "sonoff": {
      "version": "3.5.2",
      "requirements": [
        "pycryptodome>=3.6.6"
      ]
    },
    "smartir": {
      "version": "1.17.7",
      "requirements": [
        "aiofiles>=0.6.0"
      ]
    },
    "hacs": {
      "version": "1.32.1",
      "requirements": [
        "aiogithubapi>=22.10.1"
      ]
    },
    "localtuya": {
      "version": "5.2.1",
      "requirements": []
    },
    "midea_ac_lan": {
      "version": "v0.3.18",
      "requirements": []
    }
  },
  "integration_manifest": {
    "domain": "zha",
    "name": "Zigbee Home Automation",
    "after_dependencies": [
      "onboarding",
      "usb"
    ],
    "codeowners": [
      "@dmulcahey",
      "@adminiuga",
      "@puddly"
    ],
    "config_flow": true,
    "dependencies": [
      "file_upload"
    ],
    "documentation": "https://www.home-assistant.io/integrations/zha",
    "iot_class": "local_polling",
    "loggers": [
      "aiosqlite",
      "bellows",
      "crccheck",
      "pure_pcapy3",
      "zhaquirks",
      "zigpy",
      "zigpy_deconz",
      "zigpy_xbee",
      "zigpy_zigate",
      "zigpy_znp"
    ],
    "requirements": [
      "bellows==0.35.5",
      "pyserial==3.5",
      "pyserial-asyncio==0.6",
      "zha-quirks==0.0.99",
      "zigpy-deconz==0.21.0",
      "zigpy==0.55.0",
      "zigpy-xbee==0.18.0",
      "zigpy-zigate==0.11.0",
      "zigpy-znp==0.11.1"
    ],
    "usb": [
      {
        "vid": "10C4",
        "pid": "EA60",
        "description": "*2652*",
        "known_devices": [
          "slae.sh cc2652rb stick"
        ]
      },
      {
        "vid": "1A86",
        "pid": "55D4",
        "description": "*sonoff*plus*",
        "known_devices": [
          "sonoff zigbee dongle plus v2"
        ]
      },
      {
        "vid": "10C4",
        "pid": "EA60",
        "description": "*sonoff*plus*",
        "known_devices": [
          "sonoff zigbee dongle plus"
        ]
      },
      {
        "vid": "10C4",
        "pid": "EA60",
        "description": "*tubeszb*",
        "known_devices": [
          "TubesZB Coordinator"
        ]
      },
      {
        "vid": "1A86",
        "pid": "7523",
        "description": "*tubeszb*",
        "known_devices": [
          "TubesZB Coordinator"
        ]
      },
      {
        "vid": "1A86",
        "pid": "7523",
        "description": "*zigstar*",
        "known_devices": [
          "ZigStar Coordinators"
        ]
      },
      {
        "vid": "1CF1",
        "pid": "0030",
        "description": "*conbee*",
        "known_devices": [
          "Conbee II"
        ]
      },
      {
        "vid": "10C4",
        "pid": "8A2A",
        "description": "*zigbee*",
        "known_devices": [
          "Nortek HUSBZB-1"
        ]
      },
      {
        "vid": "0403",
        "pid": "6015",
        "description": "*zigate*",
        "known_devices": [
          "ZiGate+"
        ]
      },
      {
        "vid": "10C4",
        "pid": "EA60",
        "description": "*zigate*",
        "known_devices": [
          "ZiGate"
        ]
      },
      {
        "vid": "10C4",
        "pid": "8B34",
        "description": "*bv 2010/10*",
        "known_devices": [
          "Bitron Video AV2010/10"
        ]
      }
    ],
    "zeroconf": [
      {
        "type": "_esphomelib._tcp.local.",
        "name": "tube*"
      },
      {
        "type": "_zigate-zigbee-gateway._tcp.local.",
        "name": "*zigate*"
      },
      {
        "type": "_zigstar_gw._tcp.local.",
        "name": "*zigstar*"
      },
      {
        "type": "_slzb-06._tcp.local.",
        "name": "slzb-06*"
      }
    ],
    "is_built_in": true
  },
  "data": {
    "ieee": "**REDACTED**",
    "nwk": 0,
    "manufacturer": "Silicon Labs",
    "model": "EZSP",
    "name": "Silicon Labs EZSP",
    "quirk_applied": false,
    "quirk_class": "zigpy.device.Device",
    "manufacturer_code": 43981,
    "power_source": "Mains",
    "lqi": 255,
    "rssi": 0,
    "last_seen": "2023-08-28T14:36:25",
    "available": true,
    "device_type": "Coordinator",
    "signature": {
      "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Coordinator: 0>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice|AlternatePanCoordinator: 143>, manufacturer_code=43981, maximum_buffer_size=82, maximum_incoming_transfer_size=128, server_mask=11329, maximum_outgoing_transfer_size=128, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=True, *is_coordinator=True, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=False, *is_security_capable=False)",
      "endpoints": {
        "1": {
          "profile_id": "0x0104",
          "device_type": "0x0400",
          "input_clusters": [
            "0x0000",
            "0x0006",
            "0x000a",
            "0x0019",
            "0x0501"
          ],
          "output_clusters": [
            "0x0001",
            "0x0020",
            "0x0500",
            "0x0502"
          ]
        }
      },
      "manufacturer": "Silicon Labs",
      "model": "EZSP"
    },
    "active_coordinator": true,
    "entities": [],
    "neighbors": [
      {
        "device_type": "Router",
        "rx_on_when_idle": "On",
        "relationship": "Sibling",
        "extended_pan_id": "**REDACTED**",
        "ieee": "**REDACTED**",
        "nwk": "0x0BA8",
        "permit_joining": "Unknown",
        "depth": "15",
        "lqi": "199"
      },
      {
        "device_type": "Router",
        "rx_on_when_idle": "On",
        "relationship": "Sibling",
        "extended_pan_id": "**REDACTED**",
        "ieee": "**REDACTED**",
        "nwk": "0x200D",
        "permit_joining": "Unknown",
        "depth": "15",
        "lqi": "74"
      },
      {
        "device_type": "Router",
        "rx_on_when_idle": "On",
        "relationship": "Sibling",
        "extended_pan_id": "**REDACTED**",
        "ieee": "**REDACTED**",
        "nwk": "0x527C",
        "permit_joining": "Unknown",
        "depth": "15",
        "lqi": "124"
      },
      {
        "device_type": "Router",
        "rx_on_when_idle": "On",
        "relationship": "Sibling",
        "extended_pan_id": "**REDACTED**",
        "ieee": "**REDACTED**",
        "nwk": "0x5C5C",
        "permit_joining": "Unknown",
        "depth": "15",
        "lqi": "118"
      },
      {
        "device_type": "Router",
        "rx_on_when_idle": "On",
        "relationship": "Sibling",
        "extended_pan_id": "**REDACTED**",
        "ieee": "**REDACTED**",
        "nwk": "0xF139",
        "permit_joining": "Unknown",
        "depth": "15",
        "lqi": "144"
      },
      {
        "device_type": "EndDevice",
        "rx_on_when_idle": "Off",
        "relationship": "Child",
        "extended_pan_id": "**REDACTED**",
        "ieee": "**REDACTED**",
        "nwk": "0xDA82",
        "permit_joining": "NotAccepting",
        "depth": "1",
        "lqi": "95"
      },
      {
        "device_type": "EndDevice",
        "rx_on_when_idle": "Off",
        "relationship": "Child",
        "extended_pan_id": "**REDACTED**",
        "ieee": "**REDACTED**",
        "nwk": "0x4826",
        "permit_joining": "NotAccepting",
        "depth": "1",
        "lqi": "221"
      },
      {
        "device_type": "EndDevice",
        "rx_on_when_idle": "Off",
        "relationship": "Child",
        "extended_pan_id": "**REDACTED**",
        "ieee": "**REDACTED**",
        "nwk": "0x8741",
        "permit_joining": "NotAccepting",
        "depth": "1",
        "lqi": "209"
      }
    ],
    "routes": [
      {
        "dest_nwk": "0x200D",
        "route_status": "Active",
        "memory_constrained": false,
        "many_to_one": false,
        "route_record_required": false,
        "next_hop": "0xF139"
      },
      {
        "dest_nwk": "0xF139",
        "route_status": "Active",
        "memory_constrained": false,
        "many_to_one": false,
        "route_record_required": false,
        "next_hop": "0x527C"
      },
      {
        "dest_nwk": "0x5C5C",
        "route_status": "Active",
        "memory_constrained": false,
        "many_to_one": false,
        "route_record_required": false,
        "next_hop": "0x527C"
      }
    ],
    "endpoint_names": [
      {
        "name": "IAS_CONTROL"
      }
    ],
    "user_given_name": null,
    "device_reg_id": "5a40199537cebbbf65acc5c93b9375e4",
    "area_id": "a10abe9d953c452baa0a596bbb0b7599",
    "cluster_details": {
      "1": {
        "device_type": {
          "name": "IAS_CONTROL",
          "id": 1024
        },
        "profile_id": 260,
        "in_clusters": {
          "0x0000": {
            "endpoint_attribute": "basic",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0006": {
            "endpoint_attribute": "on_off",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x000a": {
            "endpoint_attribute": "time",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0019": {
            "endpoint_attribute": "ota",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0501": {
            "endpoint_attribute": "ias_ace",
            "attributes": {},
            "unsupported_attributes": {}
          }
        },
        "out_clusters": {
          "0x0001": {
            "endpoint_attribute": "power",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0020": {
            "endpoint_attribute": "poll_control",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0500": {
            "endpoint_attribute": "ias_zone",
            "attributes": {},
            "unsupported_attributes": {}
          },
          "0x0502": {
            "endpoint_attribute": "ias_wd",
            "attributes": {},
            "unsupported_attributes": {}
          }
        }
      }
    }
  }
}

Logs
Logs
[Paste the logs here]

Custom quirk
Custom quirk
[Paste your custom quirk here]

Additional information
No response

I saw there is quirk data for z2m, so I created a /config/zha_quirks/ folder, create the file Tuya_TZE204_81yrt3lo.js with this data, and added  custom_quirks_path: /config/zha_quirks/ to configuration.yaml. But after reboot and repair, still no sensors. Must I delete pycache?Have no idea how to do it...
const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const tuya = require('zigbee-herdsman-converters/lib/tuya');
const utils = require('zigbee-herdsman-converters/lib/utils');
const e = exposes.presets;
const ea = exposes.access;
const {Buffer} = require('buffer');
const valueConverter = {
divideBy10: tuya.valueConverterBasic.divideBy(10),
divideBy100: tuya.valueConverterBasic.divideBy(100),
divideBy1000: tuya.valueConverterBasic.divideBy(1000),
};
const definition = {
fingerprint: [
{
modelID: 'TS0601',
manufacturerName: '_TZE204_81yrt3lo',
},
],
model: 'TS0601_Bidirectional_Energy_Meter_with_80A_Current_Clamp',
vendor: 'TuYa',
description: 'Bidirectional Energy Meter with 80A Current Clamp',
fromZigbee: [tuya.fz.datapoints],
toZigbee: [tuya.tz.datapoints],
onEvent: tuya.onEventSetTime,
configure: tuya.configureMagicPacket,
whiteLabel: [ tuya.whitelabel('Tuya', 'PJ-1203A', 'Bidirectional Energy Meter with 80A Current Clamp', ['_TZE204_81yrt3lo']), ],
// whiteLabel: [{vendor: 'MatSeePlus', model: 'PJ-1203A'}],
exposes: [ //only report data
e.ac_frequency(),
exposes.numeric('total_power_A', ea.STATE).withUnit('W').withDescription('Total power A'),
exposes.numeric('total_power_B', ea.STATE).withUnit('W').withDescription('Total power B'),
exposes.numeric('total_power_AB', ea.STATE).withUnit('W').withDescription('Total power A'),
exposes.numeric('voltage', ea.STATE).withUnit('V').withDescription('Voltage'),
exposes.numeric('current_A', ea.STATE).withUnit('A').withDescription('Current A'),
exposes.numeric('current_B', ea.STATE).withUnit('A').withDescription('Current B'),
exposes.numeric('power_factor_A', ea.STATE).withUnit('%').withDescription('Instantaneous measured power factor A'),
exposes.numeric('power_factor_B', ea.STATE).withUnit('%').withDescription('Instantaneous measured power factor B'),
exposes.numeric('power_direction A', ea.STATE).withDescription('Power direction A 0/1 for forward/reverse'),
exposes.numeric('power_direction B', ea.STATE).withDescription('Power direction B 0/1 for forward/reverse'),
exposes.numeric('energy_forward_A', ea.STATE).withUnit('kWh').withDescription('Total energy A forward'),
exposes.numeric('energy_forward_B', ea.STATE).withUnit('kWh').withDescription('Total energy B forward'),
exposes.numeric('energy_reverse_A', ea.STATE).withUnit('kWh').withDescription('Total energy A reverse'),
exposes.numeric('energy_reverse_B', ea.STATE).withUnit('kWh').withDescription('Total energy B reverse'),
exposes.numeric('update_frequency', ea.STATE).withUnit('sec').withDescription('Update frequency'),
],
meta: {
tuyaDatapoints: [//only report data
[111, 'ac_frequency', tuya.valueConverter.divideBy100],
[101, 'total_power_A', tuya.valueConverter.divideBy10],
[105, 'total_power_B', tuya.valueConverter.divideBy10],
[115, 'total_power_AB', tuya.valueConverter.divideBy10],
[112, 'voltage', tuya.valueConverter.divideBy10],
[113, 'current_A', tuya.valueConverter.divideBy1000],
[114, 'current_B', tuya.valueConverter.divideBy1000],
[110, 'power_factor_A', tuya.valueConverter.divideBy100],
[121, 'power_factor_B', tuya.valueConverter.divideBy100],
[102, 'power_direction A', tuya.valueConverter.raw],
[104, 'power_direction B', tuya.valueConverter.raw],
[106, 'energy_forward_A', tuya.valueConverter.divideBy100],
[108, 'energy_forward_B', tuya.valueConverter.divideBy100],
[107, 'energy_reverse_A', tuya.valueConverter.divideBy100],
[109, 'energy_reverse_B', tuya.valueConverter.divideBy100],
[129, 'update_frequency' , tuya.valueConverter.raw],
],
},
};
module.exports = definition;

I think the quirk it's not applied, but I can figure why... I followed all the steps... this is the log:
"manufacturer": "_TZE204_81yrt3lo",
"model": "TS0601",
"name": "_TZE204_81yrt3lo TS0601",
"quirk_applied": false,
"quirk_class": "zigpy.device.Device",

In the opening post you have signature and diagnostic from the coordinator and not the device you have described. "device_type": "Coordinator".
Pleas updating them with information for the right device (device card).

Sorry, wrong device..... Fixed now. ( I Hope)  :-)

Tried to add custom quirk to ZHA following https://github.com/home-assistant/home-assistant.io/pull/23884/files/e03462d75c7ad37c611ab3cf4d47210f7114bc94#diff-f6bd4d42fd2565238968333a466474a25384fb4eecddc0235902e5ff5e798c8d  but still no sensors.
This means quirk isn't been applied, right? (Diagnose dump)
"manufacturer": "_TZE204_81yrt3lo",
"model": "TS0601",
"name": "_TZE204_81yrt3lo TS0601",
"quirk_applied": false,
"quirk_class": "zigpy.device.Device",
I am sure I followed all steps, creating the quirks folder and adding to yaml...
where could I start to look for the problem?

"quirk_class": "zigpy.device.Device" = the device signature is ont matching your device, so need being fixed by adding it i the right device class in the quirk of if no working one making one new for your device.

I created a file called TS0601_Router.py inside "customs_zha_quirks" folder. And zha:   enable_quirks: true   custom_quirks_path: /config/custom_zha_quirks/    to configuration.yaml
The data inside the file is `const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const tuya = require('zigbee-herdsman-converters/lib/tuya');
const utils = require('zigbee-herdsman-converters/lib/utils');
const e = exposes.presets;
const ea = exposes.access;
const {Buffer} = require('buffer');
const valueConverter = {
divideBy10: tuya.valueConverterBasic.divideBy(10),
divideBy100: tuya.valueConverterBasic.divideBy(100),
};
const definition = {
fingerprint: [
{
modelID: 'TS0601',
manufacturerName: '_TZE204_81yrt3lo',
},
],
model: 'TS0601_Bidirectional_Energy_Meter_with_80A_Current_Clamp',
vendor: 'TuYa',
description: 'Bidirectional Energy Meter with 80A Current Clamp',
fromZigbee: [tuya.fz.datapoints], //, fz.ignore_tuya_set_time not working for No converter available for friendly_name with cluster manuSpecificTuya and type commandMcuSyncTime and data {payloadSize:XXX}
toZigbee: [tuya.tz.datapoints],
onEvent: tuya.onEventSetTime, // Add this if you are getting no converter for 'commandMcuSyncTime'
configure: tuya.configureMagicPacket,
whiteLabel: [ tuya.whitelabel('Tuya', 'PJ-1203A', 'Bidirectional Energy Meter with 80A Current Clamp', ['_TZE204_81yrt3lo']), ],
// whiteLabel: [{vendor: 'MatSeePlus', model: 'PJ-1203A'}],
exposes: [ //only report data
e.ac_frequency(),
exposes.numeric('total_power_A', ea.STATE).withUnit('W').withDescription('Total power A'),
exposes.numeric('total_power_B', ea.STATE).withUnit('W').withDescription('Total power B'),
exposes.numeric('total_power_AB', ea.STATE).withUnit('W').withDescription('Total power A'),
exposes.numeric('voltage', ea.STATE).withUnit('V').withDescription('Voltage'),
exposes.numeric('current_A', ea.STATE).withUnit('A').withDescription('Current A'),
exposes.numeric('current_B', ea.STATE).withUnit('A').withDescription('Current B'),
exposes.numeric('power_factor_A', ea.STATE).withUnit('%').withDescription('Instantaneous measured power factor A'),
exposes.numeric('power_factor_B', ea.STATE).withUnit('%').withDescription('Instantaneous measured power factor B'),
exposes.numeric('power_direction A', ea.STATE).withDescription('Power direction A 0/1 for forward/reverse'),
exposes.numeric('power_direction B', ea.STATE).withDescription('Power direction B 0/1 for forward/reverse'),
exposes.numeric('energy_forward_A', ea.STATE).withUnit('kWh').withDescription('Total energy A forward'),
exposes.numeric('energy_forward_B', ea.STATE).withUnit('kWh').withDescription('Total energy B forward'),
exposes.numeric('energy_reverse_A', ea.STATE).withUnit('kWh').withDescription('Total energy A reverse'),
exposes.numeric('energy_reverse_B', ea.STATE).withUnit('kWh').withDescription('Total energy B reverse'),
exposes.numeric('update_frequency', ea.STATE).withUnit('sec').withDescription('Update frequency'),
],
meta: {
tuyaDatapoints: [//only report data
[111, 'ac_frequency', tuya.valueConverter.divideBy100],
[101, 'total_power_A', tuya.valueConverter.divideBy10],
[105, 'total_power_B', tuya.valueConverter.divideBy10],
[115, 'total_power_AB', tuya.valueConverter.divideBy10],
[112, 'voltage', tuya.valueConverter.divideBy10],
[113, 'current_A', tuya.valueConverter.divideBy100],
[114, 'current_B', tuya.valueConverter.divideBy100],
[110, 'power_factor_A', tuya.valueConverter.divideBy100],
[121, 'power_factor_B', tuya.valueConverter.divideBy100],
[102, 'power_direction A', tuya.valueConverter.raw],
[104, 'power_direction B', tuya.valueConverter.raw],
[106, 'energy_forward_A', tuya.valueConverter.divideBy100],
[108, 'energy_forward_B', tuya.valueConverter.divideBy100],
[107, 'energy_reverse_A', tuya.valueConverter.divideBy100],
[109, 'energy_reverse_B', tuya.valueConverter.divideBy100],
[129, 'update_frequency' , tuya.valueConverter.raw],
],
},
};
module.exports = definition;`
This is wrong?
THANKS for your help

You have posting Z2M code in the ZHA quirk and its not working.
You must doing one quirk from scratch if not can using one as temples and changing it so its  working for your device.

I  think one good start  i using this quirk and caning it so its working for your device if that  is using the same DPs (tuya MCU commands).
https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/ts0601_din_power.py

I bought the same device and had the same problem.
I found this information :  https://github.com/Koenkk/zigbee2mqtt/issues/18419#issuecomment-1657066719
Hope it can help to fix the problem.

Quirk applied finally, and getting some data. Only Total power delivered and Power factor. Log:
"data": {     "ieee": "**REDACTED**",     "nwk": 56699,     "manufacturer": "_TZE204_81yrt3lo",     "model": "TS0601",     "name": "_TZE204_81yrt3lo TS0601",     "quirk_applied": true,     "quirk_class": "TS0601_Router.TuyaPowerMeter_GPP",     "manufacturer_code": 4417,     "power_source": "Mains",     "lqi": 76,     "rssi": -81,     "last_seen": "2023-09-03T12:31:15",     "available": true,     "device_type": "Router",     "signature": {       "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.FullFunctionDevice|MainsPowered|RxOnWhenIdle|AllocateAddress: 142>, manufacturer_code=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",       "endpoints": {         "1": {           "profile_id": "0x0104",           "device_type": "0x0051",           "input_clusters": [             "0x0000",             "0x0004",             "0x0005",             "0x0702",             "0x0b04",             "0xef00"           ],           "output_clusters": [             "0x000a",             "0x0019"           ]         },         "242": {           "profile_id": "0xa1e0",           "device_type": "0x0061",           "input_clusters": [],           "output_clusters": [             "0x0021"           ]         }       },       "manufacturer": "_TZE204_81yrt3lo",       "model": "TS0601"     },     "active_coordinator": false,     "entities": [       {         "entity_id": "sensor.tze204_81yrt3lo_ts0601_power_factor",         "name": "_TZE204_81yrt3lo TS0601"       },       {         "entity_id": "sensor.tze204_81yrt3lo_ts0601_summation_delivered",         "name": "_TZE204_81yrt3lo TS0601"       }     ],     "neighbors": [       {         "device_type": "Coordinator",         "rx_on_when_idle": "On",         "relationship": "Parent",         "extended_pan_id": "**REDACTED**",         "ieee": "**REDACTED**",         "nwk": "0x0000",         "permit_joining": "Unknown",         "depth": "0",         "lqi": "33"       },       {         "device_type": "Router",         "rx_on_when_idle": "On",         "relationship": "Sibling",         "extended_pan_id": "**REDACTED**",         "ieee": "**REDACTED**",         "nwk": "0x527C",         "permit_joining": "Unknown",         "depth": "0",         "lqi": "112"       }     ],     "routes": [],     "endpoint_names": [       {         "name": "SMART_PLUG"       },       {         "name": "PROXY_BASIC"       }     ],     "user_given_name": null,     "device_reg_id": "c7f139fc3dc0c3829df8cef20d87199b",     "area_id": null,     "cluster_details": {       "1": {         "device_type": {           "name": "SMART_PLUG",           "id": 81         },         "profile_id": 260,         "in_clusters": {           "0x0000": {             "endpoint_attribute": "basic",             "attributes": {               "0x0001": {                 "attribute_name": "app_version",                 "value": 74               },               "0x0004": {                 "attribute_name": "manufacturer",                 "value": "_TZE204_81yrt3lo"               },               "0x0005": {                 "attribute_name": "model",                 "value": "TS0601"               }             },             "unsupported_attributes": {}           },           "0x0004": {             "endpoint_attribute": "groups",             "attributes": {},             "unsupported_attributes": {}           },           "0x0005": {             "endpoint_attribute": "scenes",             "attributes": {},             "unsupported_attributes": {}           },           "0xef00": {             "endpoint_attribute": "tuya_manufacturer",             "attributes": {               "0x0201": {                 "attribute_name": "energy",                 "value": 6580               }             },             "unsupported_attributes": {}           },           "0x0b04": {             "endpoint_attribute": "electrical_measurement",             "attributes": {               "0x0603": {                 "attribute_name": "ac_current_divisor",                 "value": 1000               },               "0x0602": {                 "attribute_name": "ac_current_multiplier",                 "value": 1               },               "0x0601": {                 "attribute_name": "ac_voltage_divisor",                 "value": 10               },               "0x0600": {                 "attribute_name": "ac_voltage_multiplier",                 "value": 1               }             },             "unsupported_attributes": {               "0x0400": {                 "attribute_name": "ac_frequency_multiplier"               },               "0x0401": {                 "attribute_name": "ac_frequency_divisor"               },               "0x0000": {                 "attribute_name": "measurement_type"               },               "0x0403": {                 "attribute_name": "power_divisor"               },               "0x0604": {                 "attribute_name": "ac_power_multiplier"               },               "0x0605": {                 "attribute_name": "ac_power_divisor"               },               "0x0402": {                 "attribute_name": "power_multiplier"               },               "0x0508": {                 "attribute_name": "rms_current"               },               "0x0505": {                 "attribute_name": "rms_voltage"               },               "0x050a": {                 "attribute_name": "rms_current_max"               },               "0x050b": {                 "attribute_name": "active_power"               },               "0x050d": {                 "attribute_name": "active_power_max"               },               "0x0507": {                 "attribute_name": "rms_voltage_max"               },               "0x050f": {                 "attribute_name": "apparent_power"               },               "0x0300": {                 "attribute_name": "ac_frequency"               },               "0x0302": {                 "attribute_name": "ac_frequency_max"               }             }           },           "0x0702": {             "endpoint_attribute": "smartenergy_metering",             "attributes": {               "0x0000": {                 "attribute_name": "current_summ_delivered",                 "value": 6580               },               "0x0302": {                 "attribute_name": "divisor",                 "value": 100               },               "0x0300": {                 "attribute_name": "unit_of_measure",                 "value": 0               }             },             "unsupported_attributes": {               "0x0400": {                 "attribute_name": "instantaneous_demand"               },               "0x0301": {                 "attribute_name": "multiplier"               },               "0x0100": {                 "attribute_name": "current_tier1_summ_delivered"               },               "0x0303": {                 "attribute_name": "summation_formatting"               },               "0x0304": {                 "attribute_name": "demand_formatting"               },               "0x0102": {                 "attribute_name": "current_tier2_summ_delivered"               },               "0x0306": {                 "attribute_name": "metering_device_type"               },               "0x0104": {                 "attribute_name": "current_tier3_summ_delivered"               },               "0x0106": {                 "attribute_name": "current_tier4_summ_delivered"               },               "0x0108": {                 "attribute_name": "current_tier5_summ_delivered"               },               "0x010a": {                 "attribute_name": "current_tier6_summ_delivered"               },               "0x0200": {                 "attribute_name": "status"               }             }           }         },         "out_clusters": {           "0x000a": {             "endpoint_attribute": "time",             "attributes": {},             "unsupported_attributes": {}           },           "0x0019": {             "endpoint_attribute": "ota",             "attributes": {},             "unsupported_attributes": {}           }         }       },       "242": {         "device_type": {           "name": "PROXY_BASIC",           "id": 97         },         "profile_id": 41440,         "in_clusters": {},         "out_clusters": {           "0x0021": {             "endpoint_attribute": "green_power",             "attributes": {},             "unsupported_attributes": {}           }         }       }     }   } }

This sentences make the difference. With this, quirk isn't applied, and device have no sensor. Doesn't matter if the signature is right, quirk isn't applied.
PROFILE_ID: zgp.PROFILE_ID,  DEVICE_TYPE: zgp.DeviceType.PROXY_BASIC,
With this, quirk is applied, but only sensors for total power and power factor are show.
PROFILE_ID: 41440,  DEVICE_TYPE: 97,
I have no idea what means the numbers or where find how it work,,,not much info about quirks development out there, anyway, I'll keep trying....

Hello, I've just read your post, even following your parameters I don't get the power entities. Can you post your file ts0601_din_power.py please?
Do you confirm that once the file is placed in the custom_zha_quirks folder, I have to clear the ts0601_din_power.cpython-311.pyc cache and reboot HA? and rebuild or do I have to delete the device and reinstall it?

Yes, every time I do any change I delete the device, delete pycache file inside zha_quirks folder, and rebbot HA.
This is what I get after repair the device (only Power factor sensor):

And this after reboot again HA (one more sensor is discovered, "Summation delivered"). More HA reboots don't add more sensors.

And this is the file ts0601_din_power.py for _TZE204_81yrt3lo I use.
`"""Tuya Din Power Meter."""
from zigpy.profiles import zha
import zigpy.types as t
from zigpy.zcl.clusters.general import Basic, Groups, Ota, Scenes, Time, GreenPowerProxy
from zigpy.zcl.clusters.homeautomation import ElectricalMeasurement
from zigpy.zcl.clusters.smartenergy import Metering
from zhaquirks import Bus, LocalDataCluster
from zhaquirks.const import (
DEVICE_TYPE,
ENDPOINTS,
INPUT_CLUSTERS,
MODELS_INFO,
OUTPUT_CLUSTERS,
PROFILE_ID,
)
from zhaquirks.tuya import (
NoManufacturerCluster,
TuyaManufClusterAttributes,
TuyaSwitch,
)
import logging
_LOGGER = logging.getLogger(name)
TUYA_TOTAL_ENERGY_ATTR = 0x0201 #total energy /100  0x0211
TUYA_CURRENT_ATTR = 0x0011      #0x0212
TUYA_POWER_ATTR = 0x0006        #0x0213
TUYA_VOLTAGE_ATTR = 0x0004      #0x0214
class TuyaManufClusterDinPower(TuyaManufClusterAttributes):
"""Manufacturer Specific Cluster of the Tuya Power Meter device."""
attributes = {
    TUYA_TOTAL_ENERGY_ATTR: ("energy", t.uint16_t, True),
    TUYA_CURRENT_ATTR: ("current", t.int16s, True),      #t.int16s
    TUYA_POWER_ATTR: ("power", t.uint64_t, True),         #t.uint16_t
    TUYA_VOLTAGE_ATTR: ("voltage", t.uint16_t, True),
}

def _update_attribute(self, attrid, value):
    #super()._update_attribute(attrid, value)
    if attrid == TUYA_TOTAL_ENERGY_ATTR:
        self.endpoint.smartenergy_metering.energy_reported(value)
        super()._update_attribute(attrid, value)
    elif attrid == TUYA_CURRENT_ATTR:
        _LOGGER.warning("TUYA_CURRENT_ATTR (0x%04x) value: %d (0x%x)" % (attrid, value, value))
    elif attrid == TUYA_POWER_ATTR:
        self.endpoint.electrical_measurement.voltage_reported((value >> 48) & 0xffff)
        self.endpoint.electrical_measurement.current_reported((value >> 24) & 0xffffff)
        self.endpoint.electrical_measurement.power_reported(value & 0xffffff)
        super()._update_attribute(TUYA_VOLTAGE_ATTR, (value >> 48) & 0xffff)
        super()._update_attribute(TUYA_CURRENT_ATTR, (value >> 24) & 0xffffff)
        super()._update_attribute(TUYA_POWER_ATTR, value & 0xffffff)
    elif attrid == TUYA_VOLTAGE_ATTR:
        _LOGGER.warning("TUYA_VOLTAGE_ATTR (0x%04x) value: %d (0x%x)" % (attrid, value, value))
    else:
        super()._update_attribute(attrid, value)
        _LOGGER.warning("attrid: 0x%04x value: %d (0x%x)" % (attrid, value, value))

class TuyaPowerMeasurement(LocalDataCluster, ElectricalMeasurement):
"""Custom class for power, voltage and current measurement."""
cluster_id = ElectricalMeasurement.cluster_id

POWER_ID = 0x050b             #0x050B
VOLTAGE_ID = 0x0505
CURRENT_ID = 0x0508

AC_VOLTAGE_MULTIPLIER = 0x0600
AC_VOLTAGE_DIVISOR = 0x0601
AC_CURRENT_MULTIPLIER = 0x0602
AC_CURRENT_DIVISOR = 0x0603

_CONSTANT_ATTRIBUTES = {AC_CURRENT_MULTIPLIER: 1, AC_CURRENT_DIVISOR: 1000, AC_VOLTAGE_MULTIPLIER: 1, AC_VOLTAGE_DIVISOR: 10}

def voltage_reported(self, value):
    """Voltage reported."""
    self._update_attribute(self.VOLTAGE_ID, value)

def power_reported(self, value):
    """Power reported."""
    self._update_attribute(self.POWER_ID, value)

def current_reported(self, value):
    """Ampers reported."""
    self._update_attribute(self.CURRENT_ID, value)

class TuyaElectricalMeasurement(LocalDataCluster, Metering):
"""Custom class for total energy measurement."""
cluster_id = Metering.cluster_id
CURRENT_SUMM_DELIVERED_ID = 0x0000
UNIT_OF_MEASURE_ID = 0x0300
MULTIPLIER_ID = 0x0301
DIVISOR_ID = 0x0302
POWER_WATT_ENUM = 0x0000

"""Setting unit of measurement."""
_CONSTANT_ATTRIBUTES = {UNIT_OF_MEASURE_ID: POWER_WATT_ENUM, DIVISOR_ID: 100}

def energy_reported(self, value):
    """Summation Energy reported."""
    self._update_attribute(self.CURRENT_SUMM_DELIVERED_ID, value)

class TuyaPowerMeter(TuyaSwitch):
"""Tuya power meter device."""
signature = {
    # "node_descriptor": "<NodeDescriptor byte1=1 byte2=64 mac_capability_flags=142 manufacturer_code=4098
    #                       maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=11264
    #                       maximum_outgoing_transfer_size=82 descriptor_capability_field=0>",
    # device_version=1
    # input_clusters=[0x0000, 0x0004, 0x0005, 0xef00]
    # output_clusters=[0x000a, 0x0019]
    MODELS_INFO: [
        ("_TZE200_byzdayie", "TS0601"),
        ("_TZE200_ewxhg6o9", "TS0601"),
        ("_TZE204_81yrt3lo", "TS0601"),
    ],
    ENDPOINTS: {
        # <SimpleDescriptor endpoint=1 profile=260 device_type=51
        # device_version=1
        # input_clusters=[0, 4, 5, 61184]
        # output_clusters=[10, 25]>
        1: {
            PROFILE_ID: zha.PROFILE_ID,
            DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
            INPUT_CLUSTERS: [
                Basic.cluster_id,
                Groups.cluster_id,
                Scenes.cluster_id,
                TuyaManufClusterAttributes.cluster_id,
            ],
            OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
        }
    },
}

replacement = {
    ENDPOINTS: {
        1: {
            PROFILE_ID: zha.PROFILE_ID,
            DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
            INPUT_CLUSTERS: [
                Basic.cluster_id,
                Groups.cluster_id,
                Scenes.cluster_id,
                TuyaManufClusterDinPower,
                TuyaPowerMeasurement,
                TuyaElectricalMeasurement,
            ],
            OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
        }
    }
}

class TuyaPowerMeter_GPP(TuyaSwitch):
"""Tuya power meter device."""
signature = {
    # "node_descriptor": "<NodeDescriptor byte1=1 byte2=64 mac_capability_flags=142 manufacturer_code=4417
    #                       maximum_buffer_size=66 maximum_incoming_transfer_size=66 server_mask=10752
    #                       maximum_outgoing_transfer_size=66 descriptor_capability_field=0>",
    # device_version=1
    # input_clusters=[0x0000, 0x0004, 0x0005, 0xef00]
    # output_clusters=[0x000a, 0x0019]
    MODELS_INFO: [
        ("_TZE200_lsanae15", "TS0601"),
        ("_TZE204_81yrt3lo", "TS0601"),
    ],
    ENDPOINTS: {
        # <SimpleDescriptor endpoint=1 profile=260 device_type=51
        # device_version=1
        # input_clusters=[0, 4, 5, 61184]
        # output_clusters=[10, 25]>
        1: {
            PROFILE_ID: zha.PROFILE_ID,
            DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
            INPUT_CLUSTERS: [
                Basic.cluster_id,
                Groups.cluster_id,
                Scenes.cluster_id,
                TuyaManufClusterAttributes.cluster_id,
            ],
            OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
        },
        242: {
            # <SimpleDescriptor endpoint=242 profile=41440 device_type=61
            # input_clusters=[]
            # output_clusters=[21]
            PROFILE_ID: 41440,
            DEVICE_TYPE: 97,
            INPUT_CLUSTERS: [],
            OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
        },
    },
}

replacement = {
    ENDPOINTS: {
        1: {
            PROFILE_ID: zha.PROFILE_ID,
            DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
            INPUT_CLUSTERS: [
                Basic.cluster_id,
                Groups.cluster_id,
                Scenes.cluster_id,
                TuyaManufClusterDinPower,
                TuyaPowerMeasurement,
                TuyaElectricalMeasurement,
            ],
            OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
        },
        242: {
            # <SimpleDescriptor endpoint=242 profile=41440 device_type=61
            # input_clusters=[]
            # output_clusters=[21]
            PROFILE_ID: 41440,
            DEVICE_TYPE: 97,
            INPUT_CLUSTERS: [],
            OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
        },
    }`

Do you think you could send me the whole file at once? I've gone step by step, but it doesn't work.

The folder must be pointed in configuration.raml, something  like
zha:   enable_quirks: true   custom_quirks_path: /config/zha_quirks/
Pointing to your quirks folder.
Can you see the quirk applied in the device info?

I read the clamp must be connected, in right position, and there must be power in the wire to get the sensors... I didn't tried with the clamp off, so, I am not sure if this is needed. I tried with Tuya app before, and only after getting all data working fine, deleted the device from tuya app and starting with ZHA.
ts0601_powermeter.zip

Yes !!
thanks for the file, it worked immediately.
the first "Power factor" sensor actually appeared on the first boot, and the second "Summation delivered" after the second reboot.
for your information, the second "Summation delivered" sensor appeared with the clamp closed (currently at 0.0kWh), my blank assembly.
I'm going back to my temporary set-up to measure a significant current.
Many thanks for this great step forward .
But I'm going to ask you again, and maybe you won't be able to answer me, the model I have has 2 sensors, and I can only see one :-(
Do you have any idea how to activate the second sensor to help me in my search?  I didn't go through TUYA, I don't have an independent gateway, and I didn't manage to associate it in Zigbee on the application.
thanks again, I'm desperate after 150 restarts.

Mine have two sensors plug too, for use with solar or wind generators. I use only one because I have no generators i+right now. This device have much more sensors, like voltage, actual consumption, etc... I am trying to get all working, but there is info (or I can't find it) about quirks creation, so I am blindfolding, just trying things....you can see all the sensors available and the entrypoints here https://github.com/Koenkk/zigbee2mqtt/issues/18419#issuecomment-1657066719  but I don't know how translate from z2mqtt to ZHA. Any progress I will post here, if any... any suggestion, progress, you make, please let me know...

OK I'm looking
yes, of course I'll publish here if I make any progress

ts0601_din_power_MatSee.zip
Hi, i made this file using TuyaPowerMeter_GPP. Not work 100% but is near.

👍 Great

You make my day, it works like charm... just have a doubt about the active power... a current of 2.4Ah at 235volts = 566W

This is the screen capture of Tuya app. It seems to need some calibration too, (is possible to modify calibration factor in the app). Last number in active power must be decimal... but you did a GREAT job. Thanks.

Great ,
is work for  me.
I have two sensors, how do I show the second one?
Is the reverse for the network already working?

Concerning the two sensors, I noticed with the latest version of @maccmaic that both sensors are present (in Manage Zigbee device) and the values updated, but I don't understand how to make them appear as entities.  In fact, I'm trying to understand the structure of the file, but the display part escapes me ;-(.

from what I saw in the code only the attributes energy_deliver_reported and  energy_deliver_reported
are being reported channel B is commented

I have tried to change delivered/recived but the integration not working.
Sorry, i dont know the architecture and is the first time programming in python.

If someone know why?
For channel B, I tried to report the CURRENT_TIER1_DELIVERED_ID attribute of the TuyaElectricalMeasurement class but it didn't work either.
The bad thing is that when I modify things that should not affect the rest, it stops showing all the entities.

dans mes recherches sur Github,  je ne vois aucun TS601 qui affiche 2 capteurs  ....
ce qui est surprenant c'est  que les données des 2 capteurs remontent bien dans ZHA, on les voit varier dans le menu " gerer l'appareil Zigbee" puis "MatSeeManufClusterDinPower" et current & currentB et avec les valeurs 0x000 et 0X001 et c'est vrai également pour la puissance et le courant

Still my summation delivered is 0. Tried a lot of things but no result... do you get the right value for it?

Hi everyone,
I managed, with a bit of fiddling, to get the second clamp to work.
I installed via HACS "zha_toolkit" and created an automation that every second calls the zha_toolkit.execute service which reads the second power and creates/updates a sensor.
Automation:
alias: aggiorno sensore
description: ""
trigger:
  - platform: time_pattern
    seconds: /1
condition: []
action:
  - service: zha_toolkit.execute
    data:
      command: attr_read
      ieee: xx:xx:xx:xx:xx:xx:xx:xx
     cluster: 0xef00
     attribute: 0x0269
      state_id: sensor.smartmeter_active_power2
      allow_create: true
mode: single

However, this sensor does not have "power" device_class and it is not possible to make a customization as the sensor is created after loading the HA customizations.
So I created a template that creates a new sensor taking as an attribute the value of "sensor.smartmeter_active_power2" created earlier.
Template
template:
  - sensor:
      - name: "Active power Isola"
         unit_of_measurement: "W"
         device_class: power
         state_class: measurement
         state: "{{ states('sensor.smartmeter_active_power2')|float(0) / 10}}"
         availability: "{{ states('sensor.smartmeter_active_power2')|is_number }}"
         icon: mdi:transmission-tower-export

In this way I have an entity for the instantaneous consumption. For the total consumption I created a "Utility Meter" helper and a template and a customization for this sensor to be able to modify the unit of measurement.
Customization:
sensor.consumo_isola3:
    friendly_name: Consumo energetico Isola
    last_reset: '1970-01-01T00:00:00+00:00'
    device_class: energy
    state_class: measurement
    unit_of_measurement: Wh

Template:
template:
  - sensor:
      - name: "Isola totale in kWh"
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: "{{ states('sensor.consumo_isola3')|float(0) / 1000 }}"
        availability: "{{ states('sensor.consumo_isola3')|is_number }}"
        icon: mdi:transmission-tower-export

Thi is the result:

I followed the wiring diagram included  withe device, that is, "A" connections for load clamp. I use only one clamp because I have no solar generator, I only want to know the energy delivered. The position of the clamp is checked by the Tuya official app, to get "Forward" indication for load circuit, or "energy delivered". All works fine this way with tuya official app, readings are right.

But with the clamp at this way, in home assistant, with this quirk, summation delivered value is always 0. So, I had to reverse the position of the clamp to get the summation delivered value working. BUT on the tuya official app this way show the clamp as reverse, and the active power is too high.. I think the "energy delicered" and "energy received" reverse in the quirk... is possible?are  is this working fine for u? How are you connections?

Hi Srjosep,
i had the same problem, i just made some change in the quirk.
This is the file i'm using
ts0601_din_power_MatSee_mod.zip
Anyway, I also don't have the solar generator but I use the second clamp to monitor another load

Hi Srjosep, i had the same problem, i just made some change in the quirk. This is the file i'm using ts0601_din_power_MatSee_mod.zip
Anyway, I also don't have the solar generator but I use the second clamp to monitor another load

Working fine now, THANKS.

Hi Srjosep, i had the same problem, i just made some change in the quirk. This is the file i'm using ts0601_din_power_MatSee_mod.zip
Anyway, I also don't have the solar generator but I use the second clamp to monitor another load

Hi, freesty82 Is your mod file running with the second clamp? You have generated a second endpoint, does that work for you? Thx!

Hi,
if you look at a couple of posts above I put a guide on how I solved it
here: https://github.com/zigpy/zha-device-handlers/issues/2549#issuecomment-1741305110

Hi, if you look at a couple of posts above I put a guide on how I solved it
here: #2549 (comment)

Thanks, I didn't see that post was yours too. So there is no way to expose the entities, right?

Hi, if you look at a couple of posts above I put a guide on how I solved it
here: #2549 (comment)

Thanks, I didn't see that post was yours too. So there is no way to expose the entities, right?

Not from tuya device itself , but with this solution you get a full usable energy  entity (sensor.active_power_isola in my setup)

hi everyone,
freesty82, I am a new home assistant user, where do you put the files automation, template and customization ?
thanks

I have the same issue. Device info TS0601 by _TZE204_81yrt3lo I installed the Quirk: (ts0601_powermeter.TuyaPowerMeter_GPP) but the sensor only shows the power delivered.
Please help me.

I have the same issue. Device info TS0601 by _TZE204_81yrt3lo I installed the Quirk: (ts0601_powermeter.TuyaPowerMeter_GPP) but the sensor only shows the power delivered. Please help me.

Hi,
you can try my modified quirk posted here https://github.com/zigpy/zha-device-handlers/issues/2549#issuecomment-1741540474

hi everyone, freesty82, I am a new home assistant user, where do you put the files automation, template and customization ? thanks

Hi,
Configuration:
you can Include the customize.yaml file (with the line below) in your configuration.yaml (if it isn't already there) and you can put the customization there
customize: !include customize.yaml
Template:
You can put the template directly in the configuration.yaml
Automation:
you can create the automation From the UI: choose Settings which is located in the sidebar, then click on Automations & Scenes

Hi,
Thanks for your work, I managed to fetch both A and B power 👍
I also need to fetch the power direction for A and B to know when solar panels are producing more power than consumed power (ie. power B can be "negative")
Look like we need to use the IDs in "MatSee Power Meter Attributes" quicks's section :
MATSEE_DPID_POWER_DIRECTION_ID_A_ATTR = 0x0266
MATSEE_DPID_POWER_DIRECTION_ID_B_ATTR = 0x0268
Not working when using service 🧰 ZHA Toolkit: Read Attribute with 0x0266 and 0x0268 ids (it works with 0x0265 and 0x0269 to fetch power)
Any chance to get these values through the quirks or with ZHA Toolkit/automation ?
Regards

Hi,
any one discovered how to show info from the second clamp?
Using the ts0601_din_power_MatSee_mod.zip I can only see the "A" clamp, data from "B" clampare not exposed.

Hi all,
I've created my own quirk for the device which is able to expose sensors within Home Assistant for both clamps:

Please do test and let me know of any issues - I plan to upstream this.
https://github.com/jeverley/zha-device-handlers/blob/dev/zhaquirks/tuya/ts0601_smart_meter.py

Please do test and let me know of any issues - I plan to upstream this once ready.

Hey @jeverley , thanks for the work you are doing with this.
My Mains sensor value is negative.
I see one of your power values is negative too.
Is that normal ?
Thanks.

My Mains sensor value is negative. I see one of your power values is negative too. Is that normal ? (Sorry , I am new to all this.) Thanks.

A couple of things you'll want to check and confirm there:

first ensure that you have both clamps wired consistently (red should go into S1, black S2)
since the clamps are directional, you should be able to flip the clamp direction around to reverse the reading it gives - there's an arrow inside the clamp that's visible when it is open that should help with helping you put it on the correct way round.

Lastly please can you confirm if you're using the latest version of the current linked file:
https://github.com/jeverley/zha-device-handlers/blob/dev/zhaquirks/tuya/ts0601_energy_meter.py
I'd have expected to see voltage and frequency reported (unless you've disabled them).

Hi @jeverley,
thanks for the wonderful work done, now I can see both clamps, now I'm doing a test remotely, but everything seems to work as it should!
some questions:

in comparison with a shelly EM (already calibrated with on the same cables I notice a significant difference, is there a way to do a fine tuning?
as in your screenshot, there are no differentiated names of the 2 calipers, is there a way to have them diversified?
where do I find the raw command to reverse the direction without turning the clamps?

thanks!!
Alessio

My Mains sensor value is negative. I see one of your power values is negative too. Is that normal ? (Sorry , I am new to all this.) Thanks.

A couple of things you'll want to check and confirm there:
* first ensure that you have both clamps wired consistently (red should go into S1, black S2)

* since the clamps are directional, you should be able to flip the clamp direction around to reverse the reading it gives - there's an arrow inside the clamp that's visible when it is open that should help with helping you put it on the correct way round.

Lastly please can you confirm if you're using the latest version of the current linked file: https://github.com/jeverley/zha-device-handlers/blob/dev/zhaquirks/tuya/ts0601_energy_meter.py
I'd have expected to see voltage and frequency reported (unless you've disabled them).

Thanks @jeverley ,
I have checked and repositioned the errant clamp and it is now showing a positive value , I had no idea there was a direction to the clamps.
Also updated to the latest version of your file and am getting the extra entities now too.
Thank you again.
Mark.

in comparison with a shelly EM (already calibrated with on the same cables I notice a significant difference, is there a way to do a fine tuning?
as in your screenshot, there are no differentiated names of the 2 calipers, is there a way to have them diversified?
where do I find the raw command to reverse the direction without turning the clamps?

Thanks for testing @agnus777, answers below:

You can adjust the reported values by writing to the coefficient attributes in the TuyaMatSeeManufCluster. Reading the product page it looks like values between 800 and 1200 are supported (80-120%):

It'd be good to know what values you find to be most accurate as I'm seeing similar (though can't vouch for the accuracy of the device I'm comparing with!)

Default naming of sensors is determined by ZHA rather than by the device/quirk, you can rename them through the UI however to suit your setup.
A command isn't being used, the value reported by the device is being applied to the power attribute (i.e. 0 =  forward, 1 means reverse i.e. negative)

I've made a further update this evening which does the following:

Removes redundant voltage and frequency sensors (it's only reading and reporting these on clamp A.
Previously I was duplicating these onto endpoint 2 so that apparent power could be calculated, this is no longer needed as I've a cleaner method of getting the value required for the calculation.
Introduce the total power attribute being reported by the device (i.e. the sum of clamp A and B power).
This can be used to report power consumption in a setup where you put one clamp on your inbound grid power and the second on your solar generation output.

See the results below:

Note I've renamed the power sensors in my setup through the UI, also Solar production currently 0 as it's night).
I'm also mapping through the current_summ_received values (i.e. power returned to grid) from the device however the ZHA integration doesn't currently have code in place to create sensors for these for zigbee devices, I'll pursue a separate PR to address that.
in the meantime you can read them into a sensor using the ZHA Toolkit attribute read service as people have mentioned earlier  in this thread when trying to read clamp B values.
Latest code still found here:
https://github.com/jeverley/zha-device-handlers/blob/dev/zhaquirks/tuya/ts0601_energy_meter.py

I've made a further update this evening which does the following:

Removes redundant voltage and frequency sensors (it's only reading and reporting these on clamp A.
Previously I was duplicating these onto endpoint 2 so that apparent power could be calculated, this is no longer needed as I've a cleaner method of getting the value required for the calculation.
Introduce the total power attribute being reported by the device (i.e. the sum of clamp A and B power).
This can be used to report power consumption in a setup where you put one clamp on your inbound grid power and the second on your solar generation output.

See the results below:

Note I've renamed the power sensors in my setup through the UI.
I'm also mapping through the current_summ_received values (i.e. power returned to grid) from the device however the ZHA integration doesn't currently have code in place to create sensors for these for zigbee devices, I'll pursue a separate PR to address that. in the meantime you can read them into a sensor using the ZHA Toolkit attribute read service as people have mentioned earlier in this thread when trying to read clamp B values.
Latest code still found here: https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter/zhaquirks/tuya/ts0601_energy_meter.py

I've made a further update this evening which does the following:

Removes redundant voltage and frequency sensors (it's only reading and reporting these on clamp A.
Previously I was duplicating these onto endpoint 2 so that apparent power could be calculated, this is no longer needed as I've a cleaner method of getting the value required for the calculation.
Introduce the total power attribute being reported by the device (i.e. the sum of clamp A and B power).
This can be used to report power consumption in a setup where you put one clamp on your inbound grid power and the second on your solar generation output.

See the results below:

Note I've renamed the power sensors in my setup through the UI.
I'm also mapping through the current_summ_received values (i.e. power returned to grid) from the device however the ZHA integration doesn't currently have code in place to create sensors for these for zigbee devices, I'll pursue a separate PR to address that. in the meantime you can read them into a sensor using the ZHA Toolkit attribute read service as people have mentioned earlier in this thread when trying to read clamp B values.
Latest code still found here: https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter/zhaquirks/tuya/ts0601_energy_meter.py

How do I apply it to HA?

I've made a further update this evening which does the following:

Removes redundant voltage and frequency sensors (it's only reading and reporting these on clamp A.
Previously I was duplicating these onto endpoint 2 so that apparent power could be calculated, this is no longer needed as I've a cleaner method of getting the value required for the calculation.
Introduce the total power attribute being reported by the device (i.e. the sum of clamp A and B power).
This can be used to report power consumption in a setup where you put one clamp on your inbound grid power and the second on your solar generation output.

See the results below:

Note I've renamed the power sensors in my setup through the UI.
I'm also mapping through the current_summ_received values (i.e. power returned to grid) from the device however the ZHA integration doesn't currently have code in place to create sensors for these for zigbee devices, I'll pursue a separate PR to address that. in the meantime you can read them into a sensor using the ZHA Toolkit attribute read service as people have mentioned earlier in this thread when trying to read clamp B values.
Latest code still found here: https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter/zhaquirks/tuya/ts0601_energy_meter.py

How do I apply it to HA?

I have the exactly same device.
When I add the device to ZHA, only the Power Factor sensors are added.

I know that the Quirck is working because I can see the "Active_Power" on the 3 endpoints in the Device Info Popup.

Do I need to force anything to add the other sensors?

I have the exactly same device.
When I add the device to ZHA, only the Power Factor sensors are added.
I know that the Quirck is working because I can see the "Active_Power" on the 3 endpoints in the Device Info Popup.
Do I need to force anything to add the other sensors?

Apologies for the delay in responding, I've been working on the PRs to expose the summation received sensors in Home Assiustant core - that functionality is now merged https://github.com/home-assistant/core/pull/107576, so I can focus my efforts on working out remaining issues with the device quirk.
Did the issue of only seeing Power factor sensors resolve after a restart of ZHA?

I have the exactly same device.
When I add the device to ZHA, only the Power Factor sensors are added.
I know that the Quirck is working because I can see the "Active_Power" on the 3 endpoints in the Device Info Popup.
Do I need to force anything to add the other sensors?

Apologies for the delay in responding, I've been working on the PRs to expose the summation received sensors in Home Assiustant core - that functionality is now merged home-assistant/core#107576, so I can focus my efforts on working out remaining issues with the device quirk.
Did the issue of only seeing Power factor sensors resolve after a restart of ZHA?

jeverley thanks for this,
I have the same issue; I can read the "active_power" value from Endpoint 1, but In my case no sensors are displayed at all. I just have 1 clamp connected.

@jeverley RE: https://github.com/home-assistant/core/pull/107576
It's not an issue in your PR, but due to how ZHA currently handles initializing attributes and creating entities, there are some "useless entities" created until ZHA has fully initialized once and ZHA restarted. Then, they stay as "ghost entities" that can be deleted.
We're currently trying to think of a proper solution for this, but could you provide the diagnostics/device signature(s) for the device(s) you need those sensors to be available on (just in case)?
If it's multiple Tuya devices that require a quirk anyway, we could assign quirk_id in quirks and match that in ZHA, so the current_summ_received only gets created for matching entities for now. (Seems like it's supported by very few devices anyway)
Just so we can "work around" the issue of creating useless entities for all power-measurement devices before the 2024.2.0 release.

Also, is there a merged quirk in the repo that could use this entity already?

Hi

@jeverley RE: home-assistant/core#107576 It's not an issue in your PR, but due to how ZHA currently handles initializing attributes and creating entities, there are some "useless entities" created until ZHA has fully initialized once and ZHA restarted. Then, they stay as "ghost entities" that can be deleted.
We're currently trying to think of a proper solution for this, but could you provide the diagnostics/device signature(s) for the device(s) you need those sensors to be available on (just in case)? If it's multiple Tuya devices that require a quirk anyway, we could assign quirk_id in quirks and match that in ZHA, so the current_summ_received only gets created for matching entities for now. (Seems like it's supported by very few devices anyway) Just so we can "work around" the issue of creating useless entities for all power-measurement devices before the 2024.2.0 release.

Hi @TheJulianJES here's my current draft PR https://github.com/zigpy/zha-device-handlers/pull/2961, it aims to add functionality for the different Tuya clamp Energy Meter devices I've tracked down.
We could potentially include a quirk_id in there, but it also includes the full list of device fingerprints that I'm mapping the value for.

Thank you all for the work, I've just integrated this Power Meter with 2 clamps through the custom quirk.
Best regards, Marco

I have the exactly same device.
When I add the device to ZHA, only the Power Factor sensors are added.
I know that the Quirck is working because I can see the "Active_Power" on the 3 endpoints in the Device Info Popup.
Do I need to force anything to add the other sensors?

Apologies for the delay in responding, I've been working on the PRs to expose the summation received sensors in Home Assiustant core - that functionality is now merged home-assistant/core#107576, so I can focus my efforts on working out remaining issues with the device quirk.
Did the issue of only seeing Power factor sensors resolve after a restart of ZHA?

I did a HA restart after the installation, but In my case, all Readings appeared suddenly after 5 days. I don't know why, but it's working like a charm now.

Thank you all for the work, I've just integrated this Power Meter with 2 clamps through the custom quirk.
Best regards, Marco

Dear Marco
which quirk exsactly you used?

Hello Eyalsac, I downloaded the ts0601_energy_meter.py file from the repository reported in the previous posts.
This should be the link: https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter/zhaquirks/tuya/ts0601_energy_meter.py

Thank you very much. Unfortunately, I can only see threepower factors. One of them is unknown.

Hello
I also pulled this code for _TZE204_81yrt3lo. Everything works properly. Would it be possible for the frequency not to be rounded to one place, but to two places after the decimal point? Then everything would be perfect for me.
In ac_frequency (id: 0x0300) it shows 5001 but rounds to 50.00
Thanks in advance
newbie in HA
Ats

Hello I also pulled this code for _TZE204_81yrt3lo. Everything works properly. Would it be possible for the frequency not to be rounded to one place, but to two places after the decimal point? Then everything would be perfect for me. In ac_frequency (id: 0x0300) it shows 5001 but rounds to 50.00 Thanks in advance newbie in HA Ats

Hi @atspro , are you using the version below?
https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
The version posted by @eyalsac is on an old branch, using the above I have the correct decimal places on my end (it's also the version I'm working actively on to support multiple devices).

Hello I also pulled this code for _TZE204_81yrt3lo. Everything works properly. Would it be possible for the frequency not to be rounded to one place, but to two places after the decimal point? Then everything would be perfect for me. In ac_frequency (id: 0x0300) it shows 5001 but rounds to 50.00 Thanks in advance newbie in HA Ats

Hi @atspro , are you using the version below?
https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
The version posted by @eyalsac is on an old branch, using the above I have the correct decimal places on my end (it's also the version I'm working actively on to support multiple devices).

Good work, many thanks for the new code. Now I have all the fields with correct data.
My question is whether it would be possible to remove the frequency rounding in the UI.
Currently, one place after the decimal point is rounded (50,0Hz)
If 4999 comes from the Unit, so that the UI also shows 49.99Hz

Hi @jeverley ,
Do you know how to reset total sum delivered and received for clamps ?
I tried overwriting values in TuyaMetering cluster endpoint 1 below (see screenshot).
It seemed to work for few seconds as I could read the 0 value I tried to write and sensor showed 0 but then it came back to original value.
I also tried to run factory reset command in Basic endpoint but doesn't seem to do anything.

Hi all,
I've added this quirk, but I don't have any values. The only ones that keep changing are the Ac Frequency and the Voltage as you can see in image.
I'm using this quirk:
https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
Any thouths why this happen?
Thanks

Hi all,
I've added this quirk, but I don't have any values. The only ones that keep changing are the Ac Frequency and the Voltage as you can see in image.
I'm using this quirk:
https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
Any thouths why this happen?
Thanks

Hi @tikes , did any start populating following a second reload of the ZHA integration?
Also what version of home assistant core are you running?

Hi @jeverley, no, already restart home assistant several times. Reload Zha. Delete and add again the device. Already follow this steps https://github.com/zigpy/zha-device-handlers/pull/2961#issuecomment-2027556480.
I'm running Core version: 2024.4.4
Thanks

Hi Guru, out there.
Mine also not populating.

Hi @jeverley , thanks so much for this quirk. This was the last device I needed to get working so now my home is complete.
I have some questions for you if you have time:

Z2M has a configuration option for update frequency. Same as the Tuya app. Can this be added also?
I have 5x summation delivered sensors. Am I correct to assume 2 are for clamps 1 and 2 consumed, 2 are for clamps 1 and 2 returned, and the 5th is for a net figure of all this?
What is apparent power actually measuring? My basic understanding is VA = W so why is my wattage use only 385ish but apparent power 709VA
Are there plans or a PR to merge this quirk into the ZHA core?

Many thanks for your work on this.

Hi folks,
I rellay struggling with the same device....
Did all as described here (e.g. tried several quirks from this side), but I got no sensors, anyway...
I have several Zigbee devices in place, such as of thermostates.
What I wondering is the fact, that there is no pycache file in the zha_quirks folder...
Any ideas, what O missed or misunderstood?
thanks in advance
Andy

Hi Guru, out there. Mine also not populating.

You need to enable the entities.

i mis the type TZE204_81yrt3lo in https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_din_power.py
is there a way to use this one https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py als normal so to use boot clamps for consumption?

Hello I also pulled this code for _TZE204_81yrt3lo. Everything works properly. Would it be possible for the frequency not to be rounded to one place, but to two places after the decimal point? Then everything would be perfect for me. In ac_frequency (id: 0x0300) it shows 5001 but rounds to 50.00 Thanks in advance newbie in HA Ats

Hi @atspro , are you using the version below?
https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
The version posted by @eyalsac is on an old branch, using the above I have the correct decimal places on my end (it's also the version I'm working actively on to support multiple devices).

Hi, the file is not availible anymore?

Hello I also pulled this code for _TZE204_81yrt3lo. Everything works properly. Would it be possible for the frequency not to be rounded to one place, but to two places after the decimal point? Then everything would be perfect for me. In ac_frequency (id: 0x0300) it shows 5001 but rounds to 50.00 Thanks in advance newbie in HA Ats

Hi @atspro , are you using the version below?
https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
The version posted by @eyalsac is on an old branch, using the above I have the correct decimal places on my end (it's also the version I'm working actively on to support multiple devices).

Hi, the file is not availible anymore?

The link works for me.

I'm a bit confused with the triple sensors :

Sometimes the 1st of the 3 is at 0 value or Unknown, sometimes it's the 3rd one.

3. What is apparent power actually measuring? My basic understanding is VA = W so why is my wattage use only 385ish but apparent power 709VA

Same question here

3. What is apparent power actually measuring? My basic understanding is VA = W so why is my wattage use only 385ish but apparent power 709VA

Same question here

This helped me understand it

Hello I also pulled this code for _TZE204_81yrt3lo. Everything works properly. Would it be possible for the frequency not to be rounded to one place, but to two places after the decimal point? Then everything would be perfect for me. In ac_frequency (id: 0x0300) it shows 5001 but rounds to 50.00 Thanks in advance newbie in HA Ats

Hi @atspro , are you using the version below?
https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
The version posted by @eyalsac is on an old branch, using the above I have the correct decimal places on my end (it's also the version I'm working actively on to support multiple devices).

I also confirm this one works for me (HAOS Home Assistant OS 13.1 - HA core-2024.9.0). How can we vote somewhere to push this quirk to standard?
Thanks @jeverley

I'm a bit confused with the triple sensors :

Sometimes the 1st of the 3 is at 0 value or Unknown, sometimes it's the 3rd one.

Were you able to understand this?? I have the same doubt.

Yes, the two first ones are the individual clamps.
Looks like the 3rd is the combination of the two, even though the values are a bit off..

Hello I also pulled this code for _TZE204_81yrt3lo. Everything works properly. Would it be possible for the frequency not to be rounded to one place, but to two places after the decimal point? Then everything would be perfect for me. In ac_frequency (id: 0x0300) it shows 5001 but rounds to 50.00 Thanks in advance newbie in HA Ats

Hi @atspro , are you using the version below?
https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
The version posted by @eyalsac is on an old branch, using the above I have the correct decimal places on my end (it's also the version I'm working actively on to support multiple devices).

I also confirm this one works for me (HAOS Home Assistant OS 13.1 - HA core-2024.9.0). How can we vote somewhere to push this quirk to standard? Thanks @jeverley

I can finally confirm that this thing works for 2 clamp power meter _TZE204_81yrt3lo. A bit of testing is ahead to see if measurements are fine.

Hi all,
I've added this quirk, but I don't have any values. The only ones that keep changing are the Ac Frequency and the Voltage as you can see in image. I'm using this quirk: https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py
Any thouths why this happen? Thanks

I've got the same issue. Anyone have workaround ?
Already deleted the pycache folder and tested several Quirks....

Having the same with this one as well, Quirk is loading, but not getting any sensors.
The one earlier in the thread did load but it only showed voltage, and nothing else.
here is the diag..
zha-01J21QD04M8BDT7GKW8BEKEJX2-_TZE204_81yrt3lo TS0601-149bc483a54ca5e43614ef19d2f20cdd.json

Hi all, it's been a while since I looked at this due to moving house.
I'm going to look at mainlining support for this as a v2 quirk, which should make it simpler to maintain and test.
It will also allow us to expose its configuration options through the Home Assistant UI.
The existing draft quirk here https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py should continue to work (and it's what I'm currently using personally), but I'll update here once I've got a v2 version ready for testing.

Hi, this - https://github.com/jeverley/zha-device-handlers/blob/ts0601_energy_meter_devices/zhaquirks/tuya/ts0601_energy_meter.py quirk is working for me. but some fields are "Unknown" like Voltage. only one field of voltage is filed. is it supposed to be like that? The same for the AC  frequency only one field is populated.

Hi there!
I've been wanting to report my experience with this little thing for a while, so here it is.
I'm using this quirk and since the beginning it was reporting negative values on all endpoints of instantaneous_demand. I even triple checked and yes, the clamps were connected as they should: s1 - red, s2 - black.
But I thought maybe I interpreted instructions wrong and I read somewhere that inverting those cables may fix it.
And it did, but then all endpoints got current_summ_received stuck on a certain value.
I tried removing and adding again this device but to no aval.
I even tried resetting the values to 0 but they return again after a short time. That makes me think... maybe it's the device the one persisting this data?
I searched and found no info on how to factory reset it.
And at this point I'm not exactly sure what to do next: reverting the cables back to factory specification maybe fixes the stuck values, but then it will return to negative values.
If I keep it I have cool graphs and all but I still cannot use HA energy feature as the values needed are stuck.
I also tried to create a counter but unit was in W and couldn't find a way to change it to Wh.
Any suggestions or tests to perform are welcomed.
Thanks for this quirk @jeverley


Use Google-style docstrings

I can see that I have the cool things to do :joy:

You were the one who suggested it ;)

We'll import lots of code from audiomentations? If yes, rewriting the docstrings will be boring. Maybe it's better to stick with the current style. Otherwise, switching to Google docstrings now doesn't cost anything, there is almost no docs ^^

Sure, we can get by without being rigid about the docstring format. Docstring format is not crucial right now


Localize release-data i18n

Partially fixes #35932.
I cloned this PR from @Sea-n 's PR: https://github.com/kubernetes/website/pull/35950 and applied the suggestions from that PR to this one.

@Sea-n what do you think?

Closed. Cannot merge this branch into main because it is based on zh-cn instead of main. See  #36375 instead.


Ruff not deepsource

Draft as I need to see whether or not all the rules is a good idea

So we can't just select = ["ALL"], we have to specifically choose some

Action naming can be changed but let's just merge


refactor: post-stage0 fixes to #3040

This pull request is only opened to run CI on stuff I may do once #3040 is
merged and stage0 updated.

Normally I do this kind of thing using a single PR which has a update stage0 commit in the middle, for example #2247 is structured like this.

I'm creating this mostly to test what would happen. Maybe we should enable CI for branches to not have to create PRa just to run CI.
(Additionally I think it's preferable to use the automatic stage0 update on master, no need to worry if the stage0 code was created cleanly.)

The point is not to use the update stage0 commit when it is actually merged, in fact it usually has to be recreated on each rebase. The point is so that the tests pass and the PR is all in one place; handling dependent PRs is more complicated, maintenance-wise, than just replacing the update-stage0 commit when bumping such a PR.

Mario, the point is that in this case the stage 0 update is not necessary as part of the original PR. I agree with Joachim that a follow-up PR is easier in this case.

In any case I should be better at marking PRs (besides marking them as Draft) that are just me trying something on the side, which may or may not turn in to real PRs :-)
I was hoping I can proceed by merging #3040, then automatic stage0 update on master, then clean-up-PR (like with #2964 and then #3105), but that may not be possible in this case, where updating stage0 will break CI until broken library code is updated.

I think a PR which fails the stage2 build should not be merged, any stage0 update and other post-stage0 fixes should be done on the same PR. If that's not the situation here, then feel free to ignore, but it sounds like #3040 still has issues of this form.

It probably has, which I am just discovering. I agree that in that case we have to go back to  the multiple-rebased-commits-including-stage0-on-one-PR workflow.


Chart sync tool requires staging-created-at argument

The chart sync tool in the wizard fails with an error that sounds as if the branch you are trying to sync did not exist. However, the real issue seems to be that the argument staging-created-at is required.
The workaround is to use the cli and pass that argument.
So I suppose that, either there is some bug in the backend (and the staging-created-at argument is not really necessary), or the wizard should ask the user to manually input that date before executing the chart sync.
This is the error I was getting now when trying to sync update-faostat-data to live:
2024-03-25 16:47:55,655 - [bugsnag] WARNING - No API key configured, couldn't notify
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/prosado/Documents/owid/repos/etl/.venv/lib/python3.11/site-packages/click/core.py", line 1157, in call
    return self.main(*args, **kwargs)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/prosado/Documents/owid/repos/etl/.venv/lib/python3.11/site-packages/rich_click/rich_command.py", line 126, in main
    rv = self.invoke(ctx)
    ^^^^^^^^^^^^^^^^
  File "/Users/prosado/Documents/owid/repos/etl/.venv/lib/python3.11/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/prosado/Documents/owid/repos/etl/.venv/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/prosado/Documents/owid/repos/etl/.venv/lib/python3.11/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/prosado/Documents/owid/repos/etl/apps/staging_sync/cli.py", line 124, in cli
    staging_created_at = _get_staging_created_at(source, staging_created_at)  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/prosado/Documents/owid/repos/etl/apps/staging_sync/cli.py", line 284, in _get_staging_created_at
    return _get_git_branch_creation_date(str(source).replace("staging-site-", ""))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/prosado/Documents/owid/repos/etl/apps/staging_sync/cli.py", line 396, in _get_git_branch_creation_date
    assert len(js) == 1, f"Branch {branch_name} not found in owid/etl repository"
    ^^^^^^^^^^^^
AssertionError: Branch update-faostat-data not found in owid/etl repository

It was caused by multiple closed branches.