Domoticz

Posted: **Thursday 16 October 2025 21:05**

Hi @edwin1234,

i would say: Wait till tomorrow, as the kWh counter will be reset at 00:00h.

Regards

Posted: **Thursday 16 October 2025 21:19**

Ok
Thank u

Posted: **Friday 17 October 2025 6:06**

I just checked it again and its not working,
Gives nan watt and nan kwh this morning and the same errors are back.

Regards

Posted: **Friday 17 October 2025 11:36**

Hello @edwin1234,

Did you check debug 9 and debug 10, that you receive a numerical value every 5 minutes during e.g. 1 hour or longer?
I asked this yesterday.

Let me know.

Regards

Posted: **Friday 17 October 2025 11:58**

Perhaps add temporarely a log message of the exact content of the message send over mqtt to Domoticz.
This way you can see in the domoticz logging of the exact content and cause of NAN and put level to error

Code: Select all

/json.htm?type=command&param=addlogmessage&message=MESSAGE&level=LEVEL

Posted: **Friday 17 October 2025 15:44**

I've just made some tests too (2024.4 version).

So, when you create the Dummy Electric device (Energy read - Computed) it has values 0 !! Kwh and 0 Watt

Then I tried to get NaN value making bad API calls to device

Code: Select all

/json.htm?type=command&param=udevice&idx=2&nvalue=0&svalue=92.1;0

/json.htm?type=command&param=udevice&idx=2&nvalue=0&svalue=192;0

/json.htm?type=command&param=udevice&idx=2&nvalue=0&svalue=92

/json.htm?type=command&param=udevice&idx=2&nvalue=0&svalue=XV

/json.htm?type=command&param=udevice&idx=2&nvalue=0&svalue=*/

And... nothing. Everything works fine, I couldn't get the NaN value

So, may be its a bug of old version of Domoticz or some bad values in database?

@edwin1234, what if you will try to delete this device and readd it again? This will clean up the DB i think. May be you will get new idx of device - pay attention.

P.S. And Today Kwh value updates and calculates every time when you update the device's values.

Posted: **Friday 17 October 2025 16:20**

Hi @habahabahaba,

I tried exactly the same and I have not been able to get NaN.
There is one thing that pops up in my mind and that is the version 2021.1.

Before version 15132 Domoticz could crash or had issues, if you sent an invalid value.
But that has been solved in 15132.
Since then Domoticz has a higher resistance against invalid values.

Version 2021.1 was 13391. So the version could cause a problem, if you send invalid values.

@edwin1234,

Could it be, that another flow is sending data to idx 1463??

That might be the reason that both habahabahaba en myself do not get those errors. (I recently updated my system to 2025.2.

Regards

Posted: **Friday 17 October 2025 18:06**

No other node red flow uses that idx.
I remove this device and make a new one and try again.

Posted: **Saturday 18 October 2025 5:51**

Still with another device i have the same error, maybe the plug itself sends something wrong,
I will buy another one and try again later.

Thank you all

Regards

Posted: **Saturday 18 October 2025 16:38**

Hello @edwin1234,

maybe the plug itself sends something wrong,

Sorry, I do not understand anymore.

I have been working with electronics since the late 1960's and I'm programming
since the early 1970's and it is the first time ever, that I hear a plug is sending something on its own.

We are also not dealing with plug-ins. So what do you mean?

I asked you already two times:

Did you check debug 9 and debug 10, that you receive a numerical value every 5 minutes during e.g. 1 hour or longer?

However you never answered that question.

Without these anwers it is very difficult to support you.

Regards

Posted: **Sunday 19 October 2025 7:13**

Hi firewizard

Sorry but with plug i meant the tuya socket itself.
I dont understand it myself anymore either
Now domoticz is giving me also an error for sending the wrong value for my enphase solar system from node red.
But thats another problem.
Could it be that something changed in node red?

I see that sometimes there is a nan value in the debug:

Posted: **Sunday 19 October 2025 11:50**

Hello @edwin1234,

Thanks for the answer.

Sorry for my previous responses, but I have been focussed to much on the refrigerator, but now I understand it is just a Smart plug with Tuya protocol

In the picture I see now a NaN in debug 10.
I cannot see it, as your "tree" is closed.

Can you click on the black arrow so that the tree opens and the source of that NaN becomes visible?
Send it again.

Regards in

Posted: **Sunday 19 October 2025 13:12**

Is nothing more to see i think

: IMG_6611.jpeg (118.43 KiB) Viewed 175 times

Posted: **Sunday 19 October 2025 17:00**

Hello @edwin1234,

Thank you.

Now I understand what is happening.

Let me explain:

The dps values send by your Tuya smart plug are changing.
I use the table, that I found at: https://github.com/dulfer/localtuya-device-datapoints
and more specifically the table for Tuya v3.3 DPs, although I do not know, if your device is a v3.3.

You see that DP ID 19 is the Power and DP ID 20 is the Voltage.

So in your message from 13:08:53 only dps: 20 has been sent. This means only the Voltage, which is 230.7 V (the value divided by 10) is available.
But this message triggers the next (Function) node and the missing Power DP 19 is interpreted as NaN and that is send by MQTT (or HTTP, if you wish) to Domoticz. Honestly, I missed it in the table Tuya v3.3. It is stated:

List of DPs for Tuya v3.3 devices.
Table contains the DPs that a device may expose. In general it is a useful lookup table to identify the DPs read by LocalTuya.

This is just a matter of testing, that DPS ID 19 exist.

Replace your existing flow with the one below:

Code: Select all

[
    {
        "id": "2bad7d3ed48f0d62",
        "type": "function",
        "z": "34725c4ec27d40dd",
        "name": "",
        "func": "msg.payload = { \"command\": \"udevice\", \"idx\": 2370, \"nvalue\" : 0, \"svalue\": (msg.payload.dps[\"19\"]/10).toString() + \";0\"};\nreturn msg;",
        "outputs": 1,
        "timeout": "",
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 640,
        "y": 640,
        "wires": [
            [
                "ec99d917d0de1c21"
            ]
        ]
    },
    {
        "id": "40a56f7737cf61c6",
        "type": "inject",
        "z": "34725c4ec27d40dd",
        "name": "",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "300",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "Koelkast",
        "payload": "{\"dps\":{\"1\":true,\"9\":0,\"18\":484,\"19\":921,\"20\":2307,\"21\":1,\"22\":558,\"23\":28166,\"24\":15267,\"25\":1364}}",
        "payloadType": "json",
        "x": 310,
        "y": 640,
        "wires": [
            [
                "251d272b34e2c618"
            ]
        ]
    },
    {
        "id": "ef81bdf4c52e2c55",
        "type": "debug",
        "z": "34725c4ec27d40dd",
        "name": "debug 9",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 640,
        "y": 580,
        "wires": []
    },
    {
        "id": "ec99d917d0de1c21",
        "type": "mqtt out",
        "z": "34725c4ec27d40dd",
        "name": "To Domoticz",
        "topic": "domoticz/in",
        "qos": "0",
        "retain": "false",
        "respTopic": "",
        "contentType": "",
        "userProps": "",
        "correl": "",
        "expiry": "",
        "broker": "175c3dc01f359e9d",
        "x": 830,
        "y": 640,
        "wires": []
    },
    {
        "id": "4259c8d387b3011b",
        "type": "debug",
        "z": "34725c4ec27d40dd",
        "name": "debug 10",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 820,
        "y": 580,
        "wires": []
    },
    {
        "id": "251d272b34e2c618",
        "type": "switch",
        "z": "34725c4ec27d40dd",
        "name": "",
        "property": "payload.dps",
        "propertyType": "msg",
        "rules": [
            {
                "t": "hask",
                "v": "19",
                "vt": "str"
            }
        ],
        "checkall": "true",
        "repair": false,
        "outputs": 1,
        "x": 470,
        "y": 640,
        "wires": [
            [
                "2bad7d3ed48f0d62"
            ]
        ]
    },
    {
        "id": "7dd5c38a2a3bfd57",
        "type": "debug",
        "z": "34725c4ec27d40dd",
        "name": "debug 13",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 460,
        "y": 580,
        "wires": []
    },
    {
        "id": "175c3dc01f359e9d",
        "type": "mqtt-broker",
        "name": "Raspberry Pi 1B",
        "broker": "192.168.10.51",
        "port": 1883,
        "clientid": "",
        "autoConnect": true,
        "usetls": false,
        "protocolVersion": 4,
        "keepalive": 60,
        "cleansession": true,
        "autoUnsubscribe": true,
        "birthTopic": "",
        "birthQos": "0",
        "birthRetain": "false",
        "birthPayload": "",
        "birthMsg": {},
        "closeTopic": "",
        "closeQos": "0",
        "closeRetain": "false",
        "closePayload": "",
        "closeMsg": {},
        "willTopic": "",
        "willQos": "0",
        "willRetain": "false",
        "willPayload": "",
        "willMsg": {},
        "userProps": "",
        "sessionExpiry": ""
    }
]

Replace the Inject node with the Tuya node and use your own MQTT settings.

Let me know.

Regards

Posted: **Sunday 19 October 2025 17:53**

Amazing that u figured that out.

I will try the new flow for a couple of hours and let you know the results.
Thank you very much.

Regards

Posted: **Monday 20 October 2025 17:56**

Hi firewizard,
Its working i have now 97,4 watt and 0 kwh
Dont know if 0 kwh is normal after 12 hours
O i see now i didnt set it on computed i wil wait a few hours again

Thanks

Regards

Posted: **Monday 20 October 2025 18:12**

I see in https://github.com/dulfer/localtuya-device-datapoints that some devices also have dps 17 Add Electricity* 0-50000 kWh
You could use that to get the kWh values in Domoticz if your device is sending them.
As it seems a delta (Add Electricity = Power consumption since last report) you will have to do some calculations with Node-red to get the right values.

Posted: **Monday 20 October 2025 18:37**

Hello both,

@edwin1234,

By default the device "Electricity (Instant+Counter)" has been set to "From device". As we do not send the Electricity the value will stay 0.
You have to set it to "Computed" and then you will see that it counts up.

@waltervl

I have no idea, what the type number of the device is. My flow has been based on the data, presented in the screenshots in this thread.
I did not see any screenshot with data point 17. If it is available, it is not difficult to use it, but the easiest would be, that it is available in the same message as data point 19. Looking to the first picture in this thread, I have my doubts.

At least, it works, even with digits after the decimal point.

Regards

Posted: **Monday 20 October 2025 19:08**

Indeed its working
And happy about that ,
Thanks again.

Regards

Domoticz

Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow

Re: Node red flow