Fatal Javascript invalid size error

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[X] I have tried the npm run clear or yarn clear command.
[X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[ ] I have tried creating a repro with https://new.docusaurus.io.
[X] I have read the console error message carefully (if applicable).

Description
yarn start inside of a docusaurus project installed with yarn 3 using the pnpm linkage mode triggers the following error:
#
# Fatal error in , line 0
# Fatal JavaScript invalid size error 169220804
#
#
#
#FailureMessage Object: 0x16fd35ba8
 1: 0x1001d8a70 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 2: 0x1010ee0b4 V8_Fatal(char const*, ...) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 3: 0x100444c90 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 4: 0x1005d122c v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 5: 0x1007d1294 v8::internal::Runtime_GrowArrayElements(int, unsigned long*, v8::internal::Isolate*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 6: 0x100b2902c Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 7: 0x1061e20b4
 8: 0x105f0a8a0
 9: 0x1065dabec
10: 0x100ab24d0 Builtins_JSEntryTrampoline [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
11: 0x100ab2164 Builtins_JSEntry [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
12: 0x1003f5ce0 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
13: 0x1003f5214 v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
14: 0x1002e57fc v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
15: 0x1000c4eec node::InternalCallbackScope::Close() [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
16: 0x1000c548c node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
17: 0x1000da310 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
18: 0x10017b8c8 node::fs::FSReqCallback::Resolve(v8::Local<v8::Value>) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
19: 0x10017c08c node::fs::AfterStat(uv_fs_s*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
20: 0x100a91c18 uv__work_done [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
21: 0x100a953b4 uv__async_io [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
22: 0x100aa712c uv__io_poll [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
23: 0x100a95844 uv_run [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
24: 0x1000c5ccc node::SpinEventLoop(node::Environment*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
25: 0x1001b1cec node::NodeMainInstance::Run(int*, node::Environment*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
26: 0x1001b19c4 node::NodeMainInstance::Run() [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
27: 0x10014a5d0 node::Start(int, char**) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
28: 0x10500d0f4

I have also seen this other issue but they were unable to make a reproduction: https://github.com/facebook/docusaurus/issues/8421
Reproducible demo
https://github.com/georeith/docusuraus-issue-fatal-size
I created this reproduction by:

Installing yarn 3 and configuring its linkageMode to pnpm
Running npx create-docusaurus@latest site classic --typescript -p yarn

(reproducible without TypeScript too)
Steps to reproduce

Clone the repo
Install yarn 3
Run yarn
Run yarn start
Click around the documentation site, within a minute it should crash and you should see a similar error in the terminal.

https://user-images.githubusercontent.com/3090066/215575595-750e953c-df2e-4d17-ad0d-85ab1b0d60a8.mp4
Expected behavior
The site should not crash
Actual behavior
The site crashes
Your environment

Public source code: https://github.com/georeith/docusuraus-issue-fatal-size
Docusaurus version used: 2.3.0
Environment name and version (e.g. Chrome 89, Node.js 16.4): Node 18.3.0, Yarn 3.3.1,
Operating system and version (e.g. Ubuntu 20.04.2 LTS): macOS Monterey (m1)

Self-service

[ ] I'd be willing to fix this bug myself.

So to clarify: you were able to reproduce this issue by just using Yarn v3, without changing any code in the init template?

First I want to say that the Yarn setup is not recommended: you should install v3 locally in .yarn/releases—the global yarn should always be the v1 one. Apart from that, I can reproduce the error, but I can't tell if it's a Yarn3 + pnpm nodeLinker issue, or really a Docusaurus issue. There doesn't seem to be anything obviously wrong from our side. Some observations:

yarn start instantly freezes. There's no way to terminate the process until it crashes.
It doesn't reproduce with using pnpm directly, or any other nodeLinker (node-modules or pnp).

First I want to say that the Yarn setup is not recommended: you should install v3 locally in .yarn/releases—the global yarn should always be the v1 one.

I check in a yarn release or use corepack normally, but what's the reasoning behind not using yarn 3 as your default?

yarn start instantly freezes. There's no way to terminate the process until it crashes.

This was my experience too

Update:
I found this issue: https://github.com/facebook/docusaurus/issues/8603
I tested docusaurus with webpack cache disabled via a plugin like so:
const disableWebpackCachePlugin = () => ({
  name: 'disableWebpackCache',
  configureWebpack() {
    return { cache: false };
  }
})

And it works.
So the issue appears to be with webpack cache and yarn 3's pnpm linker.

Can confirm that using yarn set version canary which installed 4.0.0-rc.37 is working correctly.

Great, glad you found the reason :)

For anyone else who has this problem and finds this issue, you may find yourself stuck between a rock and a hard place because even though Yarn 4 RC has a fix for this issue, if you use turbo or esbuild those will fail to install with the RC as of now.
Instead I found a workaround (it's not elegant I know) using the following postinstall script (replace site/ with your docusaurus folder in a monorepo or remove it in a standard repo):
{
  "postinstall": "rm -rf site/node_modules/@docusaurus/core/node_modules/terser-webpack-plugin/node_modules/webpack"
}

This removes the circular symlink that gets created each time yarn install runs which caused the initial issue.


Reflect down computes in 'storage' resource

The status.access.computes[].status field in the storage resource can report "Ready" even when the attached compute node is powered off.  I suspect powering off a compute after the rabbit node is up is sufficient to get in to this state.  Some mechanism is needed to keep the k8s resource status in sync with the actual hardware status.

This issue stems for nnf-ec's stale view of the link status. How exactly that link status becomes stale is under investigation.

For the time being, we'll poll the link status every minute to keep it up to date.


GEODE-5423 gradle configuration is much faster

GEODE-5423 Defer download and copy tasks to execution stage of Gradle
Custom tasks for fetching and unpacking geode-old-versions was doing
filesystem work during configure, every time a build was executed,
regardless of changes or targets requested. Reorganizing this task and
its dependencies several benefits:

moves the blocking IO heavy operation into the execution stage
allows parallel tasks to execute during the download and unzip
does not do IO checks for non-build targets like gradlew tasks
will not re-trigger the task on subsequent builds

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[x] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[x] Is your initial contribution a single, squashed commit?

[x] Does gradlew build run cleanly?

[x] Have you written or updated unit tests to verify your changes?

[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

Changed commit message

The plug-in was added, but is not publishing anywhere by default
On Jul 12, 2018 16:38, "Dan Smith"<EMAIL_ADDRESS>wrote:
@upthewaterspout approved this pull request.
It looks like you added a build-scan plugin in this PR as well? That's ok
as long as it's not publishing scans somewhere without developer's consent.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/geode/pull/2133#pullrequestreview-136865975,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/Aer30mc2OCd5Cj6aDJ2RRMGOovbYBBRCks5uF93qgaJpZM4VNdHL
.


fix(db): update field to use new encryption

:tada: This PR is included in version 1.0.0-alpha.44 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add basic RTSP endpoint API

sorry about the force pushes -- lint + no idea what's going on with config/prod.exs and config/test.exs

When it comes to the lint, it's because of different elixir versions on the CI and your PC. Try to restore previous file version and not to commit it. We are going to move to the Elixir 1.14 in the nearest future

Thanks for the review, everything should be fixed as requested


Update documentation

Fixes: https://github.com/budimanjojo/talhelper/issues/183

@budimanjojo  Yes, I think that's good, but is there anything else to consider? Like when to trigger a reboot after a config change has been performed? Or applying patches to a single node versus all nodes (I'm running into this as I target different extensions for different architectures in my cluster, for example).
Is there a common set of workflows that should be highlighted? I'm thinking of CI in these environments as well that need to be accounted for as these resources change over time.

@dmfrey I think whether or not to reboot is handled by the talosctl, it will output whether the changes require a reboot to take effect.
For applying to multiple nodes, you need to create your own script to do that.
I wouldn't recommend you to use CI though because I personally prefer using talosctl upgrade command to update talos and k8s version. They do some stuffs like checking and ensure the update success internally for you in the process and sometimes do backward compatibility in case there's breaking changes. This tool is more like having your configs IaC and help you with adding/removing nodes and keeping track of changes.

@budimanjojo Thanks for the clarification. Still new to Talos. I was doing apply-config but not seeing the updates go through and then did an upgrade and that performed the desired outcome.
I get what you're saying about the config files and the use of talhelper.


fix: [post-request-body-vars-nullability] - Fixes request body optional vars in ts code

This PR will resolve the issue of nullability for post request body nested fields.

This looks like a breaking change for others that has strict config, should we bump the version @lgandecki?


Support for Fused Attention + FP8

Summary
Cuddn supports fused_attention with FP8 inputs.
See: https://docs.nvidia.com/deeplearning/cudnn/developer-guide/index.html#flash-fused-multi-head-att-fp8
There already exists a PR on PyTorch to add support for the Cudnn Backend to SDPA:https://github.com/pytorch/pytorch/pull/101916
This seems like a potential path attention support for FP8

https://github.com/pytorch/ao/issues/560


TypeError: unsupported operand type(s) for |: 'type' and 'NodeBase'

I tried to use the command line fsapi-tools 2.0.0 but got this error both on Python 3.8 and 3.9:
fsapi-ctl get netremote.sys.info.friendlyName IP
Traceback (most recent call last):
  File "/path/fsapi-2/bin/fsapi-ctl", line 5, in <module>
    from fsapi.net.cli import main
  File "/path/fsapi-2/lib/python3.9/site-packages/fsapi/net/__init__.py", line 74, in <module>
    from .base import (
  File "/path/.virtualenvs/fsapi-2/lib/python3.9/site-packages/fsapi/net/base.py", line 716, in <module>
    _NodeListItemValue = str | NodeE8 | int | NodeValue
TypeError: unsupported operand type(s) for |: 'type' and 'NodeBase'

The simplest solution would be to use a newer version of Python, because alternative Syntax for Unions was introduced first in 3.10. In order to continue support for Python 3.8 and 3.9, I suggest to use typing.Union instead (an update should be released soon)

Didn't try that because the badge says python 3.7+ and in pyproject.toml it even lists 3.6.
I have absolutely no issue with using a newer Python version, it's just not on my Linux distribution as a centrally managed executable by default.

It seems that even though annotations are enabled this statement remains unaccepted. I will try to release a new version with a fix as soon as possible.


Introduce earthly for local and CI builds on Github Actions

Hi,
with this PR I want to switch to Github Actions as CI as travis is going to be closed.
As it was hard to reproduce build locally I want to introduce earthly as build tool to run the builds and tests on the CI the same way as run them locally. It did really help me.
What currently is missing and I would add later are tests on Windows and OS X. I hope we could start with the current matrix to enable builds again.
What I would drop is tests for pyarrow 0.16.x.
So please let me know what you think and what is missing or should be changed to bring this in.

Not sure how the settings of the repo are at the moment regarding enabling actions on branches. So this has to check an admin but you can see the lastest actions run on a PR in my fork https://github.com/bjoernmeier/turbodbc/actions/runs/541222301.

@bjoern-meier-by Will review by EOD Tuesday, would be nice to have Github Actions activated by Wednesday so that we can merge this. Review will probably take a bit longer as I don't have earthy experience yet but I'm happy to learn about it.

Not sure how the settings of the repo are at the moment regarding enabling actions on branches. So this has to check an admin but you can see the lastest actions run on a PR in my fork https://github.com/bjoernmeier/turbodbc/actions/runs/541222301.

All actions are (and have been) enabled for this repo.

Close/reopened to trigger Github Actions.

@xhochy I think the issues is how fork PRs work in github. For PRs from forks the actions are invoked from the target main/master. For PRs changing the actions they have to be part of the repo. I will address the opened points from @jochen-ott-by here and then open a PR in the repo to see the actions work.
After they are on master I will check that Ps from branches really are run with the main's workflows.

will continue on https://github.com/blue-yonder/turbodbc/pull/292 as there the actions do run


Add Zemismart SPM01 energy sensor

Proposed change
Adding Zemismart SPM01
Additional information
This patch is now only for the one phase variant since I don't own a 3-phase one.
Checklist

[X] The changes are tested and work correctly
[X] pre-commit checks pass / the code has been formatted using Black
[ ] Tests have been added to verify that the new code works

Closes #2463

The naming of the quirk file need being aliened with the other in the repro and being brand neutral but the device class can being "branded" if only one brand is using it.

Used this quirk with my SPM01 but it seams like there are some things missing. I do not get any power/current or voltage reading. Is there a way to view the raw data that is coming from the device? Any way I can help? (I also have a 3 phase version to test)

I'm only getting one sensor; power factor = unknown. The rest are missing.

@Roeland54 @simonwestenholz Please try to reconfigure the device, because it worked for me

I tried that, and even readded to device, but no luck. The info when I reconfigure is showing all the right stuff, but the sensors don't appear in HA.

In the manage device menu please read vcp_raw from the ZemismartManufCluster. You should see something like this: [176, 0, 0, 122, 3, 0, 117, 9]
Also, please attach the diagnostic file or some zha debug log of the sensor

I'm getting [149, 0, 0, 25, 3, 0, 254, 8] from vcp_raw

This is fine, now check active_power from ZemismartPowerMeasurement

Hi, when will I be able to see it in the HA/ZHA update

This is fine, now check active_power from ZemismartPowerMeasurement

It's reading 150, which seems reasonable. Odd that the sensors don't show up.

I have tried it again and suddenly the sensors did pop up. So now it is working.

For some reason I am missing the reverse energy sensor. The values in the ZemismartManufCluster do get updated. But no home assistant entity is created:

After a HA restart some of the sensors have popped up:
Why would the power factor be unknown?

I don't know either why the reverse summation doesn't show up. Only the summations, voltage, current and active power comes from the device. Recently I added the calculation for the apparent power and the power factor. I'm going to push it in a few hours.

I got the 3 phase module also installed now. There I do not get any sensors for phase 2 en 3.

Power factor is now showing, but is incorrect. Is showing as 8% but should be 80% or rather 0.8.

@simonwestenholz Try reconfiguring device and/or restarting HA. Also the apparent power should show up but it seems that it didn't.

@simonwestenholz Sorry, you were right. I was using wrong divider. Check the updated commit

@simonwestenholz Sorry, you were right. I was using wrong divider. Check the updated commit

Working now, along with apparent power. Thanks for the effort! 😊

For the energy delivered it seems like the ZHA integration in HA does not have a mapping to create a sensor for this. Must be the first ZHA device that provides this information.

I can confirm that the missing sensors (summation received and all sensors for the values of phase b and c) will need to be added in the ZHA integration to make them available in home assistant. I have "summation received" working locally with a modified ZHA. When this PR is merged I can open a PR on home assistant to add the missing sensors

@Roeland54  That's nice, thanks.
Also do you know a way to alter _decimals from the quirk or ZHA is needed to be patched? I'd like the current and voltage values to be more precise.

I had a look and the decimals are defined in the ZHA integration and the default is 1. As far as I can see you can not change it with the quirk. But it can be set in the ZHA integration. For example I have set the current to 2 decimals now:

sensors for the other phases are now also working.

I see. I changed current to 3 decimals and set voltage to show 1 decimals over 100, too.
Btw, you have weird values. Phase B voltage is so low, but current is flowing as I can see.  And active power is very small and does not exist for phases B and C.

Got active power values for the other phases already fixed. I know about the strange values for phase b. I have a delta 3 x 230v connection (no neutral). So my neutral voltage measuring wire is also connected to phase b.

How do you get the additional decimals? I've tried to add them in HA, but just get additional zeroes. Even though the raw value clearly is more accurate.

@simonwestenholz
class ElectricalMeasurementRMSCurrent(ElectricalMeasurement, id_suffix="rms_current"):
    """RMS current measurement."""

    SENSOR_ATTR = "rms_current"
    _attr_device_class: SensorDeviceClass = SensorDeviceClass.CURRENT
    _attr_name: str = "RMS current"
    _attr_native_unit_of_measurement = UnitOfElectricCurrent.AMPERE
    _div_mul_prefix = "ac_current"
+    _decimals = 3

+    def formatter(self, value: int) -> int | float:
+        """Return 'normalized' value."""
+        multiplier = getattr(
+            self._cluster_handler, f"{self._div_mul_prefix}_multiplier"
+        )
+        divisor = getattr(self._cluster_handler, f"{self._div_mul_prefix}_divisor")
+        value = float(value * multiplier) / divisor
+        if value < 100 and divisor > 1:
+            return round(value, self._decimals)
+        return round(value, self._decimals)

You do not need to add the formatter because it is inherited from ElectricalMeasurement. I think the solution here is to remove all rounding logic from ZHA. Which would be following this https://developers.home-assistant.io/blog/2023/02/08/sensor_presentation_rounding/
Currently I still have the issue that the sensors for the second and third phase are also added for the mono phase device. And because they both have the model nr: TS0601 I do not know how to filter them out.

I seem to get some spikes in the power factor value. Where the value > 100%. Maybe it would be better to filter them out?

@agocsdaniel I'm not quite comfortable finding or editing that file, sadly. Hmm. Will live with the low accuracy for now. :)

I can confirm that the missing sensors (summation received and all sensors for the values of phase b and c) will need to be added in the ZHA integration to make them available in home assistant. I have "summation received" working locally with a modified ZHA. When this PR is merged I can open a PR on home assistant to add the missing sensors

Roeland54 can you share changes which you made for ZHA to get readings from all 3 phases?

Added Zha as custom component and changed the following: [](https://github.com/Roeland54/core/commit/ac3a4e42885444daf8bb6de0befb1563ba9b6f10)

Added Zha as custom component and changed the following: Roeland54/core@ac3a4e4

Could you please help me how to do that? What should I add in to zha folder in custom_components ? I'm using your edited sensor.py file with active_power_ph_b/c. I would need to see these sensors. Thank you.

@TheJulianJES Seams like we got this to a stable working version ready to be merged. Anything we can do to help this getting merged?

how test this?

I installed the quirk for my _TZE200_ves1ycwx and I get only four entities.
vcp_* are available:

readded device
reconfigured device
ha restarted
nothing changed

I attached the diagnostic from the device. Maybe it helps.
zha-d4d9d3b2af9a3eed09d65f267d90ce73-_TZE200_ves1ycwx TS0601-b7940392b55fb65448d825afe519294f.json.txt
thanks

Looking forward for this PR to be merged, tested and looks like it is working on _tze200_ves1ycwx

Many thanks for your work! I have a 3-phase meter (identified as _TZE200_ves1ycwx) and I got it working with this quirk and @Roeland54's patch for the additional phases. It's more or less as I'd expect:

The device is connected to my heating's power input and seems to report the power usage correctly (8 kW total).
Things I have no explanation for (ignore the fact that some of the labels got translated into Bulgarian and others didn't, HA is suboptimal about translations):

No power factor/apparent power sensors for phase 0/a/x
Power factor/apparent power for phases 1/b/y and 2/c/z read as Unknown
After adding the device I had to restart to get the sensors to appear, just reconfiguring the device didn't help

I'm not sure if only some models can report power factor/apparent power or the quirk needs to be adjusted for some devices.

Power factor and apparent power where calculated values and are not part of this quirk anymore. Because they where inaccurate.
I will update the branch with zha changes to remove them.

Power factor and apparent power where calculated values and are not part of this quirk anymore. Because they where inaccurate.

Do you think it makes sense to have ZHA provide a calculated total power (the sum of the 3 phases power)? I personally created a template sensor for that but I believe it would be more convenient to get it out of the box too.

Power factor and apparent power where calculated values and are not part of this quirk anymore. Because they where inaccurate.

Do you think it makes sense to have ZHA provide a calculated total power (the sum of the 3 phases power)? I personally created a template sensor for that but I believe it would be more convenient to get it out of the box too.

You cannot simply sum all the three phases and get a correct result if your phases are not being used equally, e.g. 1 device at 220V at 1st and 2nd phases + 3 lamps at the 3rd phase + neutral

Power factor and apparent power where calculated values and are not part of this quirk anymore. Because they where inaccurate.

Do you think it makes sense to have ZHA provide a calculated total power (the sum of the 3 phases power)? I personally created a template sensor for that but I believe it would be more convenient to get it out of the box too.

No because it won't be correct if one phase is importing and another phase is exporting at the same time. There is no information about the direction of the power.

This PR should be merged so we can get going with adding full support in ZHA. Maintaining a custom version of ZHA to use this sensor is a real pain.

Thanks for the hard work getting this meter to work on ZHA.  Do you think how long will it take to get this changed merged and released?

This PR should be merged so we can get going with adding full support in ZHA. Maintaining a custom version of ZHA to use this sensor is a real pain.

I hope support coming soon, I'm newbie.. actually newer do anything python :( ,but now one of 3 phases shows data, and I think it ok.
thanks good work

Hi,
On a SPM01 by BITU TECHNIK, the sensors appear without Quirks.
But, the Power values are divided by 1000 with a poor precision (good regarding cluster, seems ac_power_divider used). So, can't be usable.
Regarding your quirck, I tried to adapt it, but I can't apply the quick even after setup the signature.
The signature read is :
  "data": {     "ieee": "**REDACTED**",     "nwk": 43057,     "manufacturer": "BITUO TECHNIK",     "model": "SPM01X001",     "name": "BITUO TECHNIK SPM01X001",     "quirk_applied": false,     "quirk_class": "zigpy.device.Device",     "quirk_id": null,     "manufacturer_code": 4630,     "power_source": "Mains",     "lqi": 216,     "rssi": -46,     "last_seen": "2024-01-06T21:01:47",     "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=4630, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, 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": "0x0501",           "input_clusters": [             "0x0000",             "0x0003",             "0x0702",             "0x0b04",             "0x0b05"           ],           "output_clusters": [             "0x0003",             "0x0019"           ]         }       },       "manufacturer": "BITUO TECHNIK",       "model": "SPM01X001"     },
The Quirck is :
`"""Tuya Din Power Meter."""
from zigpy.profiles import zha
from zigpy.quirks import CustomDevice
import zigpy.types as t
from zigpy.zcl.clusters.general import Basic, Ota, Scenes, Identify
from zigpy.zcl.clusters.homeautomation import ElectricalMeasurement, Diagnostic
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,
)
TUYA_TOTAL_ENERGY_ATTR = 0x0211
TUYA_CURRENT_ATTR = 0x0212
TUYA_POWER_ATTR = 0x0213
TUYA_VOLTAGE_ATTR = 0x0214
TUYA_DIN_SWITCH_ATTR = 0x0101
SWITCH_EVENT = "switch_event"
class TuyaPowerMeasurement(LocalDataCluster, ElectricalMeasurement):
"""Custom class for power, voltage and current measurement."""
cluster_id = ElectricalMeasurement.cluster_id

POWER_ID = 0x050B
VOLTAGE_ID = 0x0505
CURRENT_ID = 0x0508
REACTIVE_POWER_ID = 0x050E
AC_FREQUENCY_ID = 0x0300
TOTAL_REACTIVE_POWER_ID = 0x0305
POWER_FACTOR_ID = 0x0510

AC_CURRENT_MULTIPLIER = 0x0602
AC_CURRENT_DIVISOR = 0x0603
AC_FREQUENCY_MULTIPLIER = 0x0400
AC_FREQUENCY_DIVISOR = 0x0401

_CONSTANT_ATTRIBUTES = {
    AC_CURRENT_MULTIPLIER: 1,
    AC_CURRENT_DIVISOR: 1000,
    AC_FREQUENCY_MULTIPLIER: 1,
    AC_FREQUENCY_DIVISOR: 100,
}

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 / 1000)

def power_factor_reported(self, value):
    """Power Factor reported."""
    self._update_attribute(self.POWER_FACTOR_ID, value)

def reactive_power_reported(self, value):
    """Reactive Power reported."""
    self._update_attribute(self.REACTIVE_POWER_ID, value / 1000)

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

def frequency_reported(self, value):
    """AC Frequency reported."""
    self._update_attribute(self.AC_FREQUENCY_ID, value)

def reactive_energy_reported(self, value):
    """Summation Reactive Energy reported."""
    self._update_attribute(self.TOTAL_REACTIVE_POWER_ID, value)

class BituoPowerMeter(CustomDevice):
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=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264,
    # maximum_outgoing_transfer_size=82, 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)",
    # device_version=1
    # input_clusters=[0x0000, 0x0003, 0x0702, 0x0b04, 0x0b05]
    # output_clusters=[0x0003, 0x0019]
    MODELS_INFO: [
		("BITUO TECHNIK", "SPM01X001"),
    ],
    ENDPOINTS: {
        # <SimpleDescriptor endpoint=1 profile=260 device_type=51
        # device_version=1
        # input_clusters=[0, 3, 1794, 2820, 2821]
        # output_clusters=[3, 25]>
        1: {
            PROFILE_ID: zha.PROFILE_ID,
            DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
            INPUT_CLUSTERS: [
                Basic.cluster_id,
                Identify.cluster_id,
				Metering.cluster_id,
				ElectricalMeasurement.cluster_id,
				Diagnostic.cluster_id,
            ],
            OUTPUT_CLUSTERS: [Identify.cluster_id, Ota.cluster_id],
        }
    },
}

replacement = {
    ENDPOINTS: {
        1: {
            PROFILE_ID: zha.PROFILE_ID,
            DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
            INPUT_CLUSTERS: [
                Basic.cluster_id,
                Identify.cluster_id,
                TuyaPowerMeasurement,
                ElectricalMeasurement.cluster_id,
				Diagnostic.cluster_id,
            ],
            OUTPUT_CLUSTERS: [Identify.cluster_id, Ota.cluster_id],
        }
    }
}

`
Some help will be appreciate and could be merged with your Quirck.
Thank you.
Best reagrds,
Fabien

Any updates on this? Sadly I don't know how to make custom one for three phase.

Hello,
As I had many issues with this DIN power meter SPM01 "_TZE200_bcusnqt8", "TS0601".
I can confirm that this one works very nice.

How are the expectations for releasing it?

I ordered an SPM02 and was wondering when it'll be released. Would really really appreciate it if it is merged by the end of the month as that's when I'm getting my device.

I ordered an SPM02 and was wondering when it'll be released. Would really really appreciate it if it is merged by the end of the month as that's when I'm getting my device.

I bite the bullet and moved to Z2M.  Took 3-4 days to get everything back on track.

Do you think this PR could be merged soon? I'm staying on release 2024.1 because of this feature (3 phases) and I don't know if I can update to the latest release, but probably I can't. It's a bit frustrating to wait half a year to merge "a few" lines of code. I understand @TheJulianJES is very busy with other commitments but I'd really appreciate this.

@vasektomas It'll probably take a while as there will be a need to raise a PR on home assistant core as well.

There are still outstanding review comments that aren't addressed: https://github.com/zigpy/zha-device-handlers/pull/2603/files#r1459710984
Quirks v2 can now also expose custom entities without modifying HA Core. Not sure how we should deal with this case though, as the attributes mapped to are ZCL/standard.

@agocsdaniel thank you for your work, but there is still only one line to be deleted. Could you do it, so this PR could be possibly merged soon? I it would be really great to have this module in main home assistant release. Thanks in advance.

@Cubixmeister Of course. Which line?

Hello 👋
I have HZA and “TZE200_ves1ycwx” I have try few different quirks but best is only one phase shows(3-phase zemismart), power and few things amp’s etc.
I’m poor writing any python code, so I need something code what works 🫣

Just to report:
Successfully used this quirk with a Zemismart SPM-01 which identifies itself as TS0601 by _TZE200_qhlxve78. Only had to add this:
("_TZE200_qhlxve78", "TS0601"),  # SPM01

after line 398 of ts0601_din_power.py, reconfigure the device and then restart the hass instance.

@TheJulianJES Please check

Just to report:
Successfully used this quirk with a Zemismart SPM-01 which identifies itself as TS0601 by _TZE200_qhlxve78. Only had to add this:

("_TZE200_qhlxve78", "TS0601"),  # SPM01

after line 398 of ts0601_din_power.py, reconfigure the device and then restart the hass instance.

Question: "SPM01" end of line what that do? I have             ("_TZE200_ves1ycwx", "TS0601"),  # SPM02
And shows only one phase info 🤔

Question: "SPM01" end of line what that do? I have ("_TZE200_ves1ycwx", "TS0601"), # SPM02
And shows only one phase info 🤔

@mr-mmc That is just a comment, has nothing to do with anything. Earlier it was discussed that ZHA in Home Assistant can't handle data from phases 2 and 3.

So we need more code to support phases 02 and 03, right? Since having more phases is the whole point of using SPM02.

So we need more code to support phases 02 and 03, right? Since having more phases is the whole point of using SPM02.

Yes but not here. The changes needed are in home-assistant core. This pr needs to be merged first.
I did the changes for home-assistant a while back (almost a year ago) but got tired of keeping them up to date. Even if this PR gets merged this week it would take at least 2 months to get the core updated and released. If you want to use your meter. I would suggest switching to z2m.

Just to report:
Successfully used this quirk with a Zemismart SPM-01 which identifies itself as TS0601 by _TZE200_qhlxve78. Only had to add this:
("_TZE200_qhlxve78", "TS0601"),  # SPM01

after line 398 of ts0601_din_power.py, reconfigure the device and then restart the hass instance.

Question: "SPM01" end of line what that do? I have ("_TZE200_ves1ycwx", "TS0601"), # SPM02
And shows only one phase info 🤔

Same for you:   If you want to use your meter. I would suggest switching to z2m.

Understood. I'm already using z2m for some time now, but I would prefer ZHA since it seems more native from my point of view (I use Home Assistant Yellow).
At least we have the next steps defined: merge this PR and then start lobbying Home Assistant to merge the other PR.

I use Zemismart SPM-01 which identifies itself as TS0601 by _TZE200_qhlxve78 like @naorunaoru , the device seems well recognized by the quirk as seen in the screenshot, but no sensors appears

I use this quirk which seems to reference this device well

Hello,
I nerd help : I have 2 SPM01 devices at home.  The quirk is installed one device is recognized and one device is not recognized.
The signature of recognized device:
{   "node_descriptor": {     "logical_type": 1,     "complex_descriptor_available": 0,     "user_descriptor_available": 0,     "reserved": 0,     "aps_flags": 0,     "frequency_band": 8,     "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   },   "endpoints": {     "1": {       "profile_id": "0x0104",       "device_type": "0x0051",       "input_clusters": [         "0x0000",         "0x0004",         "0x0005",         "0x0702",         "0x0b04",         "0xef00"       ],       "output_clusters": [         "0x000a",         "0x0019"       ]     }   },   "manufacturer": "_TZE200_qhlxve78",   "model": "TS0601",   "class": "ts0601_din_power.TuyaZemismartPowerMeter" }
The signature of unrecognized device:
{   "node_descriptor": {     "logical_type": 1,     "complex_descriptor_available": 0,     "user_descriptor_available": 0,     "reserved": 0,     "aps_flags": 0,     "frequency_band": 8,     "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   },   "endpoints": {     "1": {       "profile_id": "0x0104",       "device_type": "0x0051",       "input_clusters": [         "0x0000",         "0x0004",         "0x0005",         "0xef00"       ],       "output_clusters": [         "0x000a",         "0x0019"       ]     }   },   "manufacturer": "_TZE200_iwn0gpzz",   "model": "TS0601",   "class": "zigpy.device.Device" }

Solved by adding this new model:
        ("_TZE200_bcusnqt8", "TS0601"),  # SPM01
        ("_TZE200_qhlxve78", "TS0601"),  # SPM01
        ("_TZE200_iwn0gpzz", "TS0601"),  # SPM01    <= Line added

Hello. Have the same model, identify itself as _TZE200_iwn0gpzz. Use this quirk with patch. Voltage, power and current is now showing. But summation is not updating. Does it works for you?

Solved by adding this new model:

    ("_TZE200_bcusnqt8", "TS0601"),  # SPM01

    ("_TZE200_qhlxve78", "TS0601"),  # SPM01

    ("_TZE200_iwn0gpzz", "TS0601"),  # SPM01    <= Line added

Hello. Have the same model, identify itself as _TZE200_iwn0gpzz. Use this quirk with patch. Voltage, power and current is now showing. But summation is not updating. Does it works for you?

Yes you are right,summation is not updating.