Temporary solution for _TZ3000_qeuvnohg

[labor4]

This PR aims to override the PR at https://github.com/dresden-elektronik/deconz-rest-plugin/pull/7012, to make these MAINS device(s) available, but also to mitigate the danger inherent to the MAINS type in that PR.

This is a temporary solution until Mains switches are handled better in Phoscon GUI.

Note that in above discussion it was argued, that security is the job for the API client. Since Phoscon GUI does not yet handle mains specifically, I suggest to merge this PR in the meantime, having:

• no lights:state/on property (disable switch)
• "type": "$TYPE_SMART_PLUG", because it currently fits better with the Phoscon GUI.

The remarks by @BabaIsYou for the similar devices ("_TZ3000_ky0fq4ho","_TZ3000_8bxrzyxz") are in this PR too, though untested by myself.

Please DEVs, review/change the timings to your likings. Thanks.

If this gets merged, then https://github.com/dresden-elektronik/deconz-rest-plugin/pull/7012 is not valid anymore.

cheers

[mattreim]

Hello @labor4 , the formatting was not correct, the duplicate uuid was removed and the intervals were optimized a bit.

_TZ3000_qeuvnohg_fuse_w_power_meter.json

[labor4]

@mattreim Thanks a lot

[github-actions[bot]]

Hey @labor4, thanks for your pull request!

[!TIP] Modified bundles can be downloaded here.

DDB changes

Modified

• tuya/_TZ3000_qeuvnohg_fuse_w_power_meter.json : TO-Q-SY1-JZT Mains/DIN Rail power switch/meter, Note the omitted /lights section :heavy_check_mark:

Validation

[!TIP] Everything is fine !

_{:clock1230: Updated for commit 2ae01bea4f5533e678474c28c15fae6179e75279}

[Smanar]

			{
					"name": "attr/swversion",
					"parse": {
						"fn": "zcl",

is now

			{
					"name": "attr/swversion",
					"parse": {
						"fn": "zcl:attr"

and other ....

[mattreim]

@labor4 , replace all "fn": "zcl" by "fn": "zcl:attr"

_TZ3000_qeuvnohg_fuse_w_power_meter.json

[labor4]

• is "description" not a valid attribute? any other field for a note/future review?
• I think it's cross-checking against a lights definition and misses "state/on". Any other way to keep this disabled for the moment, without deleting the whole "lights" section?

I can check and see what happens in Phoscon GUI if the "lights/TYPE_SMART_PLUG" section is missing. It's probably going to sort it into "sensors". Frankly I wouldn't care, since I consider this device's lights-feature a bug to begin with. I think this device should be a meter and nothing more, but this PR is intended as a heads-up for the GUI to reflect Mains, so incomplete as-intended.

What is your preference?

Shall we convert this switch into a sensor-only? What's elegant for future discussion?

I now put the note into the product field to pass validation. Maybe that would be the minimum way to communicate, that not all capabilities are honoured?

[Smanar]

is "description" not a valid attribute? any other field for a note/future review?

Not at this place, and no other fields for me, but don't worry for this.

If this device don't have state/on why do you want to create a "light" entry ? Just remove the "light" part.

[labor4]

@Smanar I‘ll take your „why“ question as an answer. I‘ll put a note into the product field, and anyone who wants to implement this properly downstream can do so.

Going to make some tests the next days.

cheers

[Smanar]

Yeah don't worry for that, some router (making only routing) have a DDF to force them visible in the API, but your device will be visible in "sensors" part, so no problem for me, can be removed.

[labor4]

Phoscon GUI cannot handle these sensors if they are not part of a SMARTPLUG. I give up.

The latest commit features sensors-only. Hopefully somebody at Phoscon GUI will have mercy and sort this out.

Thanks.

[Smanar]

Ha yes, it's a problem for phoscon, but not third app. You are using phoscon only ? You can have the value directly on the API using Phoscon/help/API Information/sensors, but not friendly.

[labor4]

Yeah I guess I could get it from the API, but this is a simple setup with no other integration/automation. I let it be for the moment.

If you can send Phoscon a note with some interest in this, much obliged from my side.

I don't know where they reside these days. Their repo seems abandonned.

[Smanar]

I m trying on the forum https://forum.phoscon.de/t/support-for-power-measurement-sensor/6296

But to be sure, you have checked on "sensor" page on Phoscon ? not "light".

Edit: After a check, it's same for me, I have a custom device (exotic stuff) it appear as light, but the consumption don't appear too. I think, for phoscon the device can appear on "light" or "sensor" but not both

[labor4]

thanks!

for the record:

my check showed, that the sensor page would show only the temperature measurement, but not power consumption (yes surprise this thing has a thermal sensor too😂).

the smartplug page shows light and power consumption, but not temperature.

anyways thanks for your effort

[Smanar]

Yeah I think it will be a problem, because Phoscon display "by device", so a device need to be a "light" or a "sensor", so they are doing "magic" to mix data, and not possible for all situations.

[labor4]

i sent dresden-elektronik a mail with explanations and a request to either

• fully integrate mains into Phoscon, with some security/safety in mind, or
• support metering on the sensors page

they replied they‘d take a look at it.