deconz-rest-plugin icon indicating copy to clipboard operation
deconz-rest-plugin copied to clipboard

Create _TZ3000_qeuvnohg_fuse_w_power_meter.json

Open cornim opened this issue 1 year ago • 4 comments

Support for Tongou Power Meter and Fuse (https://zigbee.blakadder.com/Tongou_TO-Q-SY1-JZT.html)

cornim avatar May 25 '23 16:05 cornim

It seems that Matsee Plus ATMS1602Z model could also share this DDF. Could you please change the 5 first lines of your DDF

      	"schema": "devcap1.schema.json",
      	"manufacturername": "_TZ3000_qeuvnohg",
      	"modelid": "TS011F",
      	"product": "TO-Q-SY1-JZT",
      	"vendor": "TONGOU",

by these :

      	"schema": "devcap1.schema.json",
      	"manufacturername": ["_TZ3000_qeuvnohg","_TZ3000_ky0fq4ho","_TZ3000_8bxrzyxz"],
      	"modelid": ["TS011F","TS011F","TS011F"],
      	"product": "Din smart relay with power monitoring",

thx !

BabaIsYou avatar May 30 '23 09:05 BabaIsYou

@cornim ping :)

manup avatar Aug 05 '23 12:08 manup

Hi, Thank you very much for this spec. I installed it manually.

The API shows to be working, Phoscon GUI apparently not yet. I have the 16A variant.

Question: What unit is consumption?

{
    "config": {
        "on": true,
        "reachable": true
    },
    "etag": "a4040393300873a5e0aa764fcafd36d4",
    "lastannounced": null,
    "lastseen": "2024-02-06T15:16Z",
    "manufacturername": "_TZ3000_qeuvnohg",
    "modelid": "TS011F",
    "name": "Consumption 25",
    "state": {
        "consumption": 5, 
        "lastupdated": "2024-02-06T15:12:55.026"
    },
    "type": "ZHAConsumption",
    "uniqueid": "18:7a:3e:ff:fe:47:80:33-01-0702"
}

labor4 avatar Feb 06 '24 15:02 labor4

I see a possible future problem with these kind of devices.

Since this is a mains switch, it is a category that should be handled with extra care. Because light bulbs easily survive trial'n'error config mistakes (on/off), while the consequences here might not.

Especially in Phoscon GUI there is a problematic default config, where a trigger may "shutdown all devices, even if not in a group".

So this makes it impossible by default, to keep this device safely away from human interaction.

Because of this, it may even be worth considering, to introduce a breaking addition into the API, to secure the transition of such devices into a different category, example:

should fail?
PUT     '{"on":true}'     {{baseUrl}}/api/{{APIKEY}}/lights/$NUM/state
PUT     '{"on":false}'     {{baseUrl}}/api/{{APIKEY}}/lights/$NUM/state

should succeed?
PUT     '{"onforce":true}'     {{baseUrl}}/api/{{APIKEY}}/lights/$NUM/state
PUT     '{"onforce":false}'     {{baseUrl}}/api/{{APIKEY}}/lights/$NUM/state

or?
PUT     '{"onforce":true}'     {{baseUrl}}/api/{{APIKEY}}/critical/$NUM/state
PUT     '{"onforce":false}'     {{baseUrl}}/api/{{APIKEY}}/critical/$NUM/state

So backwards-compatibility-wise it would fail by default, which is good (safe).

I don't know the full concept of your API mechanics, you know better, but you get my meaning.

Extra problem: If I reboot my router in front of my Phoscon Raspi, all Zigbee devices will shut down. Possibly triggered by interface/dhcp reconfig. (didn't investigate yet, bug present in two separate locations)

To be fair: There might be an argument to be made in this specific case, that most people (like me) want this device for its metering, and not for the switch. So to be able to disable the switch might be a more common use case.

Best regards

labor4 avatar Feb 10 '24 23:02 labor4