Closed DerElch87 closed 1 year ago
@d0np3p3 Hacking the TBGW is not helping then its only serial communication between the Zigbee module and the network controller CPU. You can listening to it with normal TTL serial cables on the PCB connectors (not populated).
I think it's easier / better sniffing the Zigbee traffic then the tuya ZBGW is talking with the device (like then you is setting time programs) then you can getting all information how the ZBGW is handling the device in real in one standard way.
Also tuya have disabling all "normal" debug on the Zigbee module so no use using SWD for debugging its not getting any on the pins (if you is halting the CPU and like looking in registers its still possible but not useful) :-(
PS: I is using one hacked tuya ZBGW and coordinator and one hacked LIDL as network based Zigbee sniffer :-)))
How could I sniff the traffic, I also have a sonoff ZigBee USB Stick?
@MattWestb i "modded" LIDL GW as well, but i (still) didn't use it for sniff, i have other kind of problem, because mine LIDL remote controllers not triggering any action, using 3 platform, meaning Z2M(texas instruments cc2531), ZHA (though lidl-hacked gateway (i thought it would be more compatible)https://paulbanks.org/projects/lidl-zigbee/#home-assistant-integration ) and stock another lidl gateway + tuya cloud integration, last method, work but poor. i have all 3 simultaneously, so i can observe it, but i starting to give up from https://community.home-assistant.io/t/zha-lidl-livarnolux-zigbee-remote-control-can-it-work/365248/8 those RC, because IKEA RC work ok, but LIDL(tuya) after pairing show only battery status, i tried to insert external translator .js file, but im not skilled enough for that, and as i use home assistant supervised, not let me poke&peek much in containers, or at least i don't know how to "mess" with internal libraries..
https://community.home-assistant.io/t/zha-lidl-livarnolux-zigbee-remote-control-can-it-work/365248/8 but probably those RC cant work on these platforms because they use proprietary codes, but then i don't know why other people saying https://www.zigbee2mqtt.io/devices/FB20-002.html are supported and working, may be older or newer FW version...
I think from the beginning is sending normal light steering command on, off dimm up and down what i have read in ZHA.
But then pressing on
one second time and no off between its changing mode and starting sending "tuya zigbee commands" (for changing scenes in tuya lights).
LIDL have getting one new batch of there 3 plug with 4 USB and its have newer firmware that is not Zigbee certified (the original is) and its only having one endpoint and all plugs is reacting as one. So it can being very likely tuya have cooking some new undocumented futures in your remotes if they have new firmware. You can checking the firmware and comparing with working ones and is its new then its the reason (your is very likely on the latest then you have then with LIDL ZBGW).
I think the light steering part is easy fixing but the scene mode need good debug logging or sniffing what its being sent in Zigbee part between the device and tuya ZBGW.
You can using the ptched tuya ZBGW to sniffing the not patched ZBGW only need installing bellow from Zigpy and using its CLI and dumping the radio traffic and using wireshark for looking in the files.
Coding Java is not my side so i cant helping with that.
if I'd have simple buttons triggers in HA, no scene need, i would be more than happy, as i already bought few of those RC, but as you told "I think the light steering part is easy fixing"i really don't know where to dig...
I spent 7 days with no results, so i will taking a break (because it driving me crazy) before continue on deeper digging, in meantime i can only search for more alternatives, i can bind RC to group and put some lights in group, but then i don't have feedback to home assistant when somebody turn light, and i don't have any automation possibility. but thank you for sharing opinion. i use x86 nuc managed HASS.os so no much to peek'n'poke on it, i have to obtain some "raspi" to be able to sniff'n'dump ZB.. and new 7 day of rock-breaking would earn enough to buy another 2 ikea working RC :).... regards.
Hi. Is there any chance those will start working at some point? I have just bought a few of them, i was planning to use them for multiple different things but actually watering is not on the top of the list - so i am mainly interested in on/off functionality without a timer. I can see that the device supports custom timer variables, which should allow me to set it to a long value and periodically reset the device so it's constantly in on state. The problem is that it doesnt report the current state back to the Zigbee, so i can never be sure if it's on and off. Is this something what may ever get fixed (ie. something what is working on the original lidl hub) or simply the device has only one way communication?
Hello, i think you already know this from the iot tuya device debug Page, but maybe not... `
switch | Boolean | "{true,false}" -- | -- | -- countdown | Integer | { "unit": "min", "min": 1, "max": 599, "scale": 0, "step": 1 } countdown_left | Integer | { "unit": "min", "min": 0, "max": 599, "scale": 0, "step": 1 } battery_percentage | Integer | { "unit": "%", "min": 0, "max": 100, "scale": 0, "step": 1 }`
@d0np3p3 could you please link that page to this issue ?
I Gott No issue, I just want to help to fully support this device, until then i will use tuya Hub and fhem
I'm just asking you to provide a link to the page :) helping everyone gathering information about how to support this device
https://eu.iot.tuya.com/ Its from my account within https://eu.iot.tuya.com/ there are also the logs if i change timer
@d0np3p3 Do you have the possibility sniffing the device then its paring with tuya ZBGW and also after that sending commands and to / from it ?
I think we need casting "tuya magic" spells on this device for it behaving OK and we have getting it working with 2 other tuya problem devices the last week.
Sorry I just use the Cloud to add the device via Tuya to HA, even it if not supported yet, i now use my old fhem. You cannot see anything about paring, with other devices are you talking about?
@MattWestb I have some traces captured some time ago... Already offered here ;-) As gateway is meanwhile decomissioned I have no longer doubts to share network key... May this help Parkside Water -Wireshark.zip
Thanks @Main-pinguin !!
I was looking in the pair und setFiltered1.pcapng
and the device is paring as normal Zigbee 3 device and the tuya TBGW is reading the normal "tuya magic" attributes:
ZigBee Network Layer Data, Dst: 0x053e, Src: 0x0000
ZigBee Application Support Layer Data, Dst Endpt: 255, Src Endpt: 1
Frame Control Field: Data (0x40)
Destination Endpoint: 255
Cluster: Basic (0x0000)
Profile: Home Automation (0x0104)
Source Endpoint: 1
Counter: 66
ZigBee Cluster Library Frame, Command: Read Attributes, Seq: 33
Frame Control Field: Profile-wide (0x10)
Sequence Number: 33
Command: Read Attributes (0x00)
Attribute: Manufacturer Name (0x0004)
Attribute: ZCL Version (0x0000)
Attribute: Application Version (0x0001)
Attribute: Model Identifier (0x0005)
Attribute: Power Source (0x0007)
Attribute: Unknown (0xfffe)
responce:
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
Frame Control Field: Data (0x00)
Destination Endpoint: 1
Cluster: Basic (0x0000)
Profile: Home Automation (0x0104)
Source Endpoint: 1
Counter: 59
ZigBee Cluster Library Frame, Command: Read Attributes Response, Seq: 33
Frame Control Field: Profile-wide (0x18)
Sequence Number: 33
Command: Read Attributes Response (0x01)
Status Record, String: _TZE200_htnnfasr
Attribute: Manufacturer Name (0x0004)
Status: Success (0x00)
Data Type: Character String (0x42)
String: _TZE200_htnnfasr
Status Record, Uint8: 3
Attribute: ZCL Version (0x0000)
Status: Success (0x00)
Data Type: 8-Bit Unsigned Integer (0x20)
Uint8: 3 (0x03)
Status Record, Uint8: 86
Attribute: Application Version (0x0001)
Status: Success (0x00)
Data Type: 8-Bit Unsigned Integer (0x20)
Uint8: 86 (0x56)
Status Record, String: TS0601
Attribute: Model Identifier (0x0005)
Status: Success (0x00)
Data Type: Character String (0x42)
String: TS0601
Status Record
Attribute: Power Source (0x0007)
Status: Success (0x00)
Data Type: 8-Bit Enumeration (0x30)
Power Source: Battery (0x03)
Status Record, Enum8: 0
Attribute: Unknown (0xfffe)
Status: Success (0x00)
Data Type: 8-Bit Enumeration (0x30)
Uint8: 0 (0x00)
So 100% this device need the "tuya magic spell" being casted on it then its joining the network.
Then its requesting updating the link key add its looks normal and also doing one normal time request and response (with Zigbee commands not tuya DP/MCU commands).
Then the device is start sending strange commands to / from basic cluster and also form tuya DP/MCU cluster so its one very strange hybrid device.
So if some like digging deeper its the first fixing the "tuya magic" and then looking what commands its using from basic and the tuya DP/MCU cluster.
I dont have the device and also not the code knowledge for doing that but im very sure some other have that can can making the device working in our open systems.
@MattWestb, exactly like you said. I was analyzing this about year ago, and had similar thoughts. There were some messages between device and gw that couldn't be replicated by zigbee2mqtt at the time. I think situation didn't change, because as I remember from that time, there were some values to be changed in z2m responses that were "hardcoded" very deep in the whole solution. I was trying to replicate whole communication anyway, but I was not able to make it exactly the same, so I gave up.
Looks like the device also need one attribute being written after the first casted spell:
IEEE 802.15.4 Data, Dst: 0x053e, Src: 0x2ebe
ZigBee Network Layer Data, Dst: 0x053e, Src: 0x0000
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
ZigBee Cluster Library Frame, Command: Write Attributes, Seq: 34
Frame Control Field: Profile-wide (0x10)
Sequence Number: 34
Command: Write Attributes (0x02)
Attribute Field, Uint8: 13
Attribute: Unknown (0xffde)
Data Type: 8-Bit Unsigned Integer (0x20)
Uint8: 13 (0x0d)
IEEE 802.15.4 Data, Dst: 0x2ebe, Src: 0x053e
ZigBee Network Layer Data, Dst: 0x0000, Src: 0x053e
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
ZigBee Cluster Library Frame, Command: Write Attributes Response, Seq: 34
Frame Control Field: Profile-wide (0x18)
Sequence Number: 34
Command: Write Attributes Response (0x04)
Status Record
Status: Success (0x00)
Then the tuya MCU is sending ll DP commands is using to the coordinator:
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
Frame Control Field: Data (0x00)
Destination Endpoint: 1
Cluster: Unknown (0xef00)
Profile: Home Automation (0x0104)
Source Endpoint: 1
Counter: 67
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 100
Command: Unknown (0x02)
Data (10 bytes)
Data: 00190502000400000001
[Length: 10]
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 101
Command: Unknown (0x02)
Data (10 bytes)
Data: 001a0b0200040000005a
[Length: 10]
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 102
Command: Unknown (0x02)
Data (8 bytes)
Data: 001b6b0000020000
[Length: 8]
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 103
Command: Unknown (0x02)
Data (16 bytes)
Data: 001c6500000a00ffff00000000000000
[Length: 16]
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 104
Command: Unknown (0x02)
Data (16 bytes)
Data: 001d6600000a00ffff00000000000000
[Length: 16]
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 105
Command: Unknown (0x02)
Data (16 bytes)
Data: 001e6700000a00ffff00000000000000
[Length: 16]
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 106
Command: Unknown (0x02)
Data (16 bytes)
Data: 001f6800000a00ffff00000000000000
[Length: 16]
ZigBee Cluster Library Frame, Command: Default Response, Seq: 107
Frame Control Field: Profile-wide (0x00)
Sequence Number: 107
Command: Default Response (0x0b)
Response to Command: 0x02
Status: Success (0x00)
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 108
Command: Unknown (0x02)
Data (16 bytes)
Data: 00216a00000a00ffff00000000000000
[Length: 16]
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 109
Command: Unknown (0x02)
Data (10 bytes)
Data: 00220602000400000000
[Length: 10]
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x09)
Sequence Number: 110
Command: Unknown (0x02)
Data (15 bytes)
Data: 002301010001000502000400000001
[Length: 15]
And after that the coordinator is sending one strange unknown command on the basic cluster many times (i dont know if its important or not):
ZigBee Network Layer Data, Dst: 0x053e, Src: 0x0000
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
Frame Control Field: Data (0x40)
Destination Endpoint: 1
Cluster: Basic (0x0000)
Profile: Home Automation (0x0104)
Source Endpoint: 1
Counter: 94
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x11)
Sequence Number: 38
Command: Unknown (0xf0)
If some one is good calculating the tuya DPs is all there (if the sniffer have missing some frames).
@mgrom we have making the "tuya magic spell" for the dimmer switch TS004F that need the same for activating 3 extra end points and its working good on 3 open systems included Z2M.so if some can using that code on this device its very likely start working "normally" in tuya way and sending DP commands OK that can being used for getting the function working OK.
Here is the first version of the tuya magic implanted in TS004F Dimmer Switch: https://github.com/Koenkk/zigbee-herdsman-converters/blob/e104abdca8cb4b4c24d908dd9f66b9dd7d414250/devices/tuya.js#L774-L798 Try implanting the same for this device and im very sure its start working more normal.
I was looking one more time and cant see any strange manufacture flagged frames or so only normal "tuya magic" that is easy implanting.
@MattWestb Sorry I didn't find the time to look into in detail. However as I play around with this fancy device some specails are discovered... Seems that date and tim is sent to device. I setup a schedule in device and took it to another location. The valve did keep the schedule even without been conected to gateway... As well but not proved the recurring ativity seems to working without connection to gateway... May be this is a hint to the information exchanged during peering...
Here is the first version of the tuya magic implanted in TS004F Dimmer Switch: https://github.com/Koenkk/zigbee-herdsman-converters/blob/e104abdca8cb4b4c24d908dd9f66b9dd7d414250/devices/tuya.js#L774-L798 Try implanting the same for this device and im very sure its start working more normal.
@MattWestb thank you for pointing us in the right direction. I played around with this stuff the last days and it seems that it's working now!
The biggest problem for me was that sending the tuya magic never succeeded in the configure method. After some trial and error I figured out that I just had to send it again or more respectively retrigger the configuration via the frontend. I have no idea why, but sending it instantly in the configure method does not work. But it seems to be enough to add a delay and send the tuya magic afterwards :grimacing: I paired it several times and it worked every time on my dev setup.
Finally, I got the following states to work:
The device is also reporting DP 101, 102, 103, 104, 105, 106 and 107 after successful pairing. But I have no idea what these codes mean:
Debug Received Zigbee message from '0x847127fffea98364', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0],"type":"Buffer"},"datatype":0,"dp":107}],"seq":41473}' from endpoint 1 with groupID 0
Warning zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #107 with data {"dp":107,"datatype":0,"data":{"type":"Buffer","data":[0,0]}}
Debug Received Zigbee message from '0x847127fffea98364', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,255,255,0,0,0,0,0,0,0],"type":"Buffer"},"datatype":0,"dp":101}],"seq":41729}' from endpoint 1 with groupID 0
Warning zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #101 with data {"dp":101,"datatype":0,"data":{"type":"Buffer","data":[0,255,255,0,0,0,0,0,0,0]}}
Debug Received Zigbee message from '0x847127fffea98364', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,255,255,0,0,0,0,0,0,0],"type":"Buffer"},"datatype":0,"dp":102}],"seq":41985}' from endpoint 1 with groupID 0
Warning zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #102 with data {"dp":102,"datatype":0,"data":{"type":"Buffer","data":[0,255,255,0,0,0,0,0,0,0]}}
Debug Received Zigbee message from '0x847127fffea98364', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,255,255,0,0,0,0,0,0,0],"type":"Buffer"},"datatype":0,"dp":103}],"seq":42241}' from endpoint 1 with groupID 0
Warning zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #103 with data {"dp":103,"datatype":0,"data":{"type":"Buffer","data":[0,255,255,0,0,0,0,0,0,0]}}
Debug Received Zigbee message from '0x847127fffea98364', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,255,255,0,0,0,0,0,0,0],"type":"Buffer"},"datatype":0,"dp":104}],"seq":42497}' from endpoint 1 with groupID 0
Warning zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #104 with data {"dp":104,"datatype":0,"data":{"type":"Buffer","data":[0,255,255,0,0,0,0,0,0,0]}}
Debug Received Zigbee message from '0x847127fffea98364', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,255,255,0,0,0,0,0,0,0],"type":"Buffer"},"datatype":0,"dp":105}],"seq":42753}' from endpoint 1 with groupID 0
Warning zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #105 with data {"dp":105,"datatype":0,"data":{"type":"Buffer","data":[0,255,255,0,0,0,0,0,0,0]}}
Debug Received Zigbee message from '0x847127fffea98364', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,255,255,0,0,0,0,0,0,0],"type":"Buffer"},"datatype":0,"dp":106}],"seq":43009}' from endpoint 1 with groupID 0
Warning zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #106 with data {"dp":106,"datatype":0,"data":{"type":"Buffer","data":[0,255,255,0,0,0,0,0,0,0]}}
If someone wants to play around with this stuff, that's my external converter:
parkside-watering-timer.js
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 tuya = require('zigbee-herdsman-converters/lib/tuya');
const e = exposes.presets;
const ea = exposes.access;
const tuyaLocal = {
dataPoints: {
parksideWateringTimer: 5,
parksideWateringTimerLeft: 6,
parksideWateringBattery: 11,
},
};
const fzLocal = {
lidl_watering_timer: {
cluster: 'manuSpecificTuya',
type: ['commandDataReport'],
convert: (model, msg, publish, options, meta) => {
const result = {};
for (const dpValue of msg.data.dpValues) {
const dp = dpValue.dp; // First we get the data point ID
const value = tuya.getDataValue(dpValue); // This function will take care of converting the data to proper JS type
switch (dp) {
case tuya.dataPoints.state:
result.state = value ? 'ON' : 'OFF';
break;
case tuyaLocal.dataPoints.parksideWateringTimer:
// value reported in minutes
result.timer = value;
break;
case tuyaLocal.dataPoints.parksideWateringTimerLeft: {
// value reported in minutes
result.timer_time_left = value;
break;
}
case tuyaLocal.dataPoints.parksideWateringBattery: {
// value reported in percent
result.battery = value;
break;
}
default: {
meta.logger.warn(`zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #${dp} with data ${JSON.stringify(dpValue)}`);
}
}
}
return result;
},
},
};
const tzLocal = {
lidl_watering_timer: {
key: ['timer'],
convertSet: (entity, key, value, meta) => {
tuya.sendDataPointRaw(entity, tuyaLocal.dataPoints.parksideWateringTimer, tuya.convertDecimalValueTo4ByteHexArray(value));
},
},
};
const definition = {
fingerprint: [{modelID: 'TS0601', manufacturerName: '_TZE200_htnnfasr'}],
model: 'PSBZS A1',
vendor: 'Lidl',
description: 'Parkside smart watering timer',
fromZigbee: [fz.ignore_basic_report, fz.ignore_tuya_set_time, fzLocal.lidl_watering_timer],
toZigbee: [tz.on_off, tzLocal.lidl_watering_timer],
onEvent: tuya.onEventSetTime,
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
// no idea why, but we have to wait, otherwise the next request will fail!
await new Promise((resolve) => setTimeout(resolve, 1000));
// activate reporting
await endpoint.read('genBasic', ['manufacturerName', 'zclVersion', 'appVersion', 'modelId', 'powerSource', 0xfffe]);
},
exposes: [
e.switch().setAccess('state', ea.STATE_SET),
e.battery(),
exposes.numeric('timer', ea.SET).withValueMin(1).withValueMax(10000).withUnit('min').withDescription('Auto off after specific time.'),
exposes.numeric('timer_time_left', exposes.access.STATE).withUnit('min').withDescription('Auto off timer time left'),
],
};
module.exports = definition;
Just place it next to your configuration.yaml and add the following content to your config:
external_converters:
- parkside-watering-timer.js
I think (= not knowing) that most device its possible casting the spell after the device is pared and initiated only the TS004F Dimmer switch need having it before start configuring the device (the device need being in INIT mode for adding 3 new endpoints).
If its working OK doing one reconfigure i think its OK.
The TS004F is forgetting the spell then being retested and the battery is being out but is being kept if only retested or still having the network setting then taking the battery out.
You can try doing one reset of your device and after that taking the battery out and testing if its working OK.
The new DPs is very likely status / alarms from the device but not so easy finding out if not knowing how the device is working. Hopefully some with tuya integration and the device can looking what tuya is calling the DP and we can implanting them.
One you can finding if putting in one pair nearly empty batteries and see is its sending one DP for battery alarm.
And tuya DP / MCU device is normally sending all DPs its using then being paired (if all is going well) or after power on so you have getting all DPs the device is using :-))
@zinserjan you're the man :) It's working great!! Thank you
@d0np3p3 can you looking if you can find what DP 101, 102, 103, 104, 105, 106 and 107 is for function in tuya cloud ? Now the device is sending them OK and only need to knowing what it is for implanting it in the code.
@d0np3p3 can you looking if you can find what DP 101, 102, 103, 104, 105, 106 and 107 is for function in tuya cloud ? Now the device is sending them OK and only need to knowing what it is for implanting it in the code.
I've just went through my posts from last year and I've found that 107 was already decoded by me:
DP: 0x6b data: 0x00 0x70 means -> 0x00 weekly schedule and 0x70 <=> 1110000 (sunday, saturday, friday, .... monday) so it's ON on sun, sat, and fri. data: 0x01 0x05 means -> 0x01 cycle schedule and 0x05 means every 5th day.
One you can finding if putting in one pair nearly empty batteries and see is its sending one DP for battery alarm.
That doesn't make any difference. The reporting is still the same except the lower battery value.
But while replacing batteries I noticed some new reports about genOnOff
that was reporting the current on/off state - unfortunately it's pretty unreliable. I verified the reporting with an interval of 1 min in different scenarios and I'm pretty sure right now, that it's broken. The reporting is only correct if you turn the device on and off via Zigbee - all other cases like timeout or toggle button doesn't affect the reporting.
Heres my update to "disable" and ignore the on/off reporting via genOnOff
.
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 tuya = require('zigbee-herdsman-converters/lib/tuya');
const e = exposes.presets;
const ea = exposes.access;
const tuyaLocal = {
dataPoints: {
parksideWateringTimer: 5,
parksideWateringTimerLeft: 6,
parksideWateringBattery: 11,
},
};
const fzLocal = {
lidl_watering_timer: {
cluster: 'manuSpecificTuya',
type: ['commandDataReport'],
convert: (model, msg, publish, options, meta) => {
const result = {};
for (const dpValue of msg.data.dpValues) {
const dp = dpValue.dp; // First we get the data point ID
const value = tuya.getDataValue(dpValue); // This function will take care of converting the data to proper JS type
switch (dp) {
case tuya.dataPoints.state:
result.state = value ? 'ON' : 'OFF';
break;
case tuyaLocal.dataPoints.parksideWateringTimer:
// value reported in minutes
result.timer = value;
break;
case tuyaLocal.dataPoints.parksideWateringTimerLeft: {
// value reported in minutes
result.timer_time_left = value;
break;
}
case tuyaLocal.dataPoints.parksideWateringBattery: {
// value reported in percent
result.battery = value;
break;
}
default: {
meta.logger.warn(`zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #${dp} with data ${JSON.stringify(dpValue)}`);
}
}
}
return result;
},
},
};
const tzLocal = {
lidl_watering_timer: {
key: ['timer'],
convertSet: (entity, key, value, meta) => {
tuya.sendDataPointRaw(entity, tuyaLocal.dataPoints.parksideWateringTimer, tuya.convertDecimalValueTo4ByteHexArray(value));
},
},
};
const definition = {
fingerprint: [{modelID: 'TS0601', manufacturerName: '_TZE200_htnnfasr'}],
model: 'PSBZS A1',
vendor: 'Lidl',
description: 'Parkside smart watering timer',
fromZigbee: [fz.ignore_basic_report, fz.ignore_tuya_set_time, fz.ignore_onoff_report, fzLocal.lidl_watering_timer],
toZigbee: [tz.on_off, tzLocal.lidl_watering_timer],
onEvent: tuya.onEventSetTime,
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
// no idea why, but we have to wait, otherwise the next request will fail!
await new Promise((resolve) => setTimeout(resolve, 1000));
// activate reporting
await endpoint.read('genBasic', ['manufacturerName', 'zclVersion', 'appVersion', 'modelId', 'powerSource', 0xfffe]);
// set reporting interval of genOnOff to max to "disable" it
// background: genOnOff reporting does not respect timer or button, that makes the on/off reporting pretty unreliable
// the device is reporting it's state change anyway via tuya DPs, so we just lose the continous state report
await reporting.bind(endpoint, coordinatorEndpoint, ['genOnOff']);
await reporting.onOff(endpoint, { max: 0xFFFF });
},
exposes: [
e.switch().setAccess('state', ea.STATE_SET),
e.battery(),
exposes.numeric('timer', ea.SET).withValueMin(1).withValueMax(10000).withUnit('min').withDescription('Auto off after specific time.'),
exposes.numeric('timer_time_left', exposes.access.STATE).withUnit('min').withDescription('Auto off timer time left'),
],
};
module.exports = definition;
@d0np3p3 can you looking if you can find what DP 101, 102, 103, 104, 105, 106 and 107 is for function in tuya cloud ? Now the device is sending them OK and only need to knowing what it is for implanting it in the code.
DP IDs from IOT Cloud: Switch Coutdown timer1 countdown left timer2 timer3 timer4 timer5 timer6 Battery Percentive repeate Day shedule Shedule Reset
Set Shedule looks like this:
2022-03-28 00:00:04 Report repeate Day AAA= device itself
2022-03-26 23:00:08 Report timer6 AP//AAAAAAAAAA== device itself
ror while opening serialport 'Error: Error: No such file or directory, cannot open /dev/ttyACM0'
The error is: 'Error while opening serialport 'Error: Error: No such file or directory, cannot open /dev/ttyACM0' )
This is the connection to your zigbee2mqtt usb-stick and I think this has nothing to do with the parkside integration.
There's also something about frost detection. Whenever the temperature is below 5 degrees celcius, the default hub gets a notification warning and the device itself stops working (protection mode). You can unblock this protection via de app. There must be an endpoint for that I guess.
One you can finding if putting in one pair nearly empty batteries and see is its sending one DP for battery alarm.
That doesn't make any difference. The reporting is still the same except the lower battery value.
But while replacing batteries I noticed some new reports about
genOnOff
that was reporting the current on/off state - unfortunately it's pretty unreliable. I verified the reporting with an interval of 1 min in different scenarios and I'm pretty sure right now, that it's broken. The reporting is only correct if you turn the device on and off via Zigbee - all other cases like timeout or toggle button doesn't affect the reporting.Heres my update to "disable" and ignore the on/off reporting via
genOnOff
.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 tuya = require('zigbee-herdsman-converters/lib/tuya'); const e = exposes.presets; const ea = exposes.access; const tuyaLocal = { dataPoints: { parksideWateringTimer: 5, parksideWateringTimerLeft: 6, parksideWateringBattery: 11, }, }; const fzLocal = { lidl_watering_timer: { cluster: 'manuSpecificTuya', type: ['commandDataReport'], convert: (model, msg, publish, options, meta) => { const result = {}; for (const dpValue of msg.data.dpValues) { const dp = dpValue.dp; // First we get the data point ID const value = tuya.getDataValue(dpValue); // This function will take care of converting the data to proper JS type switch (dp) { case tuya.dataPoints.state: result.state = value ? 'ON' : 'OFF'; break; case tuyaLocal.dataPoints.parksideWateringTimer: // value reported in minutes result.timer = value; break; case tuyaLocal.dataPoints.parksideWateringTimerLeft: { // value reported in minutes result.timer_time_left = value; break; } case tuyaLocal.dataPoints.parksideWateringBattery: { // value reported in percent result.battery = value; break; } default: { meta.logger.warn(`zigbee-herdsman-converters:Parkside Watering Timer: NOT RECOGNIZED DP #${dp} with data ${JSON.stringify(dpValue)}`); } } } return result; }, }, }; const tzLocal = { lidl_watering_timer: { key: ['timer'], convertSet: (entity, key, value, meta) => { tuya.sendDataPointRaw(entity, tuyaLocal.dataPoints.parksideWateringTimer, tuya.convertDecimalValueTo4ByteHexArray(value)); }, }, }; const definition = { fingerprint: [{modelID: 'TS0601', manufacturerName: '_TZE200_htnnfasr'}], model: 'PSBZS A1', vendor: 'Lidl', description: 'Parkside smart watering timer', fromZigbee: [fz.ignore_basic_report, fz.ignore_tuya_set_time, fz.ignore_onoff_report, fzLocal.lidl_watering_timer], toZigbee: [tz.on_off, tzLocal.lidl_watering_timer], onEvent: tuya.onEventSetTime, configure: async (device, coordinatorEndpoint, logger) => { const endpoint = device.getEndpoint(1); // no idea why, but we have to wait, otherwise the next request will fail! await new Promise((resolve) => setTimeout(resolve, 1000)); // activate reporting await endpoint.read('genBasic', ['manufacturerName', 'zclVersion', 'appVersion', 'modelId', 'powerSource', 0xfffe]); // set reporting interval of genOnOff to max to "disable" it // background: genOnOff reporting does not respect timer or button, that makes the on/off reporting pretty unreliable // the device is reporting it's state change anyway via tuya DPs, so we just lose the continous state report await reporting.bind(endpoint, coordinatorEndpoint, ['genOnOff']); await reporting.onOff(endpoint, { max: 0xFFFF }); }, exposes: [ e.switch().setAccess('state', ea.STATE_SET), e.battery(), exposes.numeric('timer', ea.SET).withValueMin(1).withValueMax(10000).withUnit('min').withDescription('Auto off after specific time.'), exposes.numeric('timer_time_left', exposes.access.STATE).withUnit('min').withDescription('Auto off timer time left'), ], }; module.exports = definition;
Thanks very much for this!
There's also something about frost detection. Whenever the temperature is below 5 degrees celcius, the default hub gets a notification warning and the device itself stops working (protection mode). You can unblock this protection via de app. There must be an endpoint for that I guess.
Regular tuya bridge allows you to unlock device. Without that you need to remove batteries.
Put the device in the freezer and waiting for what DP is sending (we have doing the same with tuya TRVs for finding frost detect and window open alarms).
Put the device in the freezer and waiting for what DP is sending (we have doing the same with tuya TRVs for finding frost detect and window open alarms).
Already tried that a few days ago - it's DP 108.
Debug Received Zigbee message from '0x847127fffea84a0f', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":108}],"seq":11520}' from endpoint 1 with groupID 0
Debug Received Zigbee message from '0x847127fffea84a0f', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":6}],"seq":11776}' from endpoint 1 with groupID 0
Debug Received Zigbee message from '0x847127fffea84a0f', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0],"type":"Buffer"},"datatype":1,"dp":1},{"data":{"data":[0,0,0,6],"type":"Buffer"},"datatype":2,"dp":5}],"seq":12032}' from endpoint 1 with groupID 0
There was only a single message after 30 minutes in the freezer. Sending false again to the same DP didn't unlock the device. I had to remove the batteries to unlock it...
Very likely the device need one reset command after have sending the alarm (if some pipes was damages it shall not start working by its self). Try sending the other unknown DP to the device and see if its sending "normal" on DP 108.
Some tuya TRV is having one DP for reporting alarms and one other for enabling and disabling the function like valve jammed detection On/Off and the alarm then its having problems.
Some one with one tuya ZBGW and one freezer that can sniffing the function then resetting the alarm after letting the device warming up ?
I've just went through my posts from last year and I've found that 107 was already decoded by me:
DP: 0x6b data: 0x00 0x70 means -> 0x00 weekly schedule and 0x70 <=> 1110000 (sunday, saturday, friday, .... monday) so it's ON on sun, sat, and fri. data: 0x01 0x05 means -> 0x01 cycle schedule and 0x05 means every 5th day.
Nice job @mgrom. I already integrated this stuff, but wasn't able to test it without the watering config.
But I just analyzed the wireshark files from @Main-pinguin today and DP 101 - 106 is definitely the watering cycle:
DP 101 disable cyclus 00120002000000000001 => 0x00 disabled, 0x12 start hour 18, 0x00 start minute 00, 0x02 watering duration 2 hours, 0x00 watering duration 00 minutes
DP 101 enable cyclus at 18:00 for 2 hours 01120002000000000001 => 0x01 enabled, 0x12 start hour 18, 0x00 start minute 00, 0x02 watering duration 2 hours, 0x00 watering duration 00 minutes
I'm not really sure what the other bytes are for, but it might be something like remaining time, countdown, etc. I'll look into it in the next days.
Some one with one tuya ZBGW and one freezer that can sniffing the function then resetting the alarm after letting the device warming up ?
That would be awesome!
Here we are (setup of watering sequence) - valve put in fridge - (change of sequence) - frost alert - no action of valve on set time - remove from fridge - wait for warm up - (reset alert) | actions done on ZBGW are in brackets Watering in fridge.zip
Here we are (setup of watering sequence) - valve put in fridge - (change of sequence) - frost alert - no action of valve on set time - remove from fridge - wait for warm up - (reset alert) | actions done on ZBGW are in brackets Watering in fridge.zip
Nice! Can you share your network key for decrypting?
For sure .. My mistake that I didn't include into ZIP... 570805518c2175fee87b8edf14436cdf
If im not wrong is the frame 2067 (Arrival Time: Mar 31, 2022 11:24:21.183943000 W. Europe Summer Time) the command for resetting the the frost alarm:
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
Frame Control Field: Data (0x40)
Destination Endpoint: 1
Cluster: Unknown (0xef00)
Profile: Home Automation (0x0104)
Source Endpoint: 1
Counter: 165
ZigBee Cluster Library Frame
Frame Control Field: Cluster-specific (0x11)
Sequence Number: 43
Command: Unknown (0x00)
Data (7 bytes)
Data: 00286d04000100
[Length: 7]
and the data is 00286d04000100
that need being parsed as one tuya DP command.
Some one can calculating the DP ?
And great thanks one more time to @Main-pinguin !!
PS: Command type 0x00 is sent from tuya ZBGW to the device and command 0x02 is reported commands from the device to the ZBGW.
NP You're welcome
P.S. the time for reset fit to log in Tuya app ;-)
Looking forward to implement the valves now into my automation system without any baypass solution.
Thx to all for taking care of development
Here is the full list of commands (only ignored the battery reporting):
Frame 18 at Mar 31, 2022 10:35:30.715918000 CEST 0x0000 -> 0x58e9 DP 1 Data: 010502000400000001
Frame 22 at Mar 31, 2022 10:35:30.835894000 CEST 0x58e9 -> 0x0000 DP 6 Data: 00000001
Frame 28 at Mar 31, 2022 10:35:30.955327000 CEST 0x58e9 -> 0x0000 DP 1 Data: 010502000400000001
Frame 45 at Mar 31, 2022 10:35:41.252000000 CEST 0x0000 -> 0x58e9 DP 1 Data: 000502000400000001
Frame 49 at Mar 31, 2022 10:35:41.372977000 CEST 0x58e9 -> 0x0000 DP 6 Data: 00000000
Frame 55 at Mar 31, 2022 10:35:41.490377000 CEST 0x58e9 -> 0x0000 DP 1 Data: 000502000400000001
Frame 81 at Mar 31, 2022 10:36:11.958214000 CEST 0x0000 -> 0x58e9 DP 107 Data: 007f
Frame 85 at Mar 31, 2022 10:36:12.067102000 CEST 0x58e9 -> 0x0000 DP 107 Data: 007f
Frame 126 at Mar 31, 2022 10:37:00.973001000 CEST 0x0000 -> 0x58e9 DP 101 Data: 010a2800020002000002
Frame 130 at Mar 31, 2022 10:37:01.100008000 CEST 0x58e9 -> 0x0000 DP 101 Data: 010a2800020002000002
Frame 282 at Mar 31, 2022 10:40:25.492279000 CEST 0x58e9 -> 0x0000 DP 6 Data: 00000000
Frame 288 at Mar 31, 2022 10:40:25.612115000 CEST 0x58e9 -> 0x0000 DP 1 Data: 010502000400000001
Frame 858 at Mar 31, 2022 10:54:30.720137000 CEST 0x0000 -> 0x58e9 DP 101 Data: 010a2800020000140002
Frame 862 at Mar 31, 2022 10:54:30.846929000 CEST 0x58e9 -> 0x0000 DP 101 Data: 010a2800020000140002
Frame 960 at Mar 31, 2022 10:57:02.382164000 CEST 0x58e9 -> 0x0000 DP 108 Data: 01
Frame 966 at Mar 31, 2022 10:57:02.501999000 CEST 0x58e9 -> 0x0000 DP 6 Data: 00000000
Frame 972 at Mar 31, 2022 10:57:02.617877000 CEST 0x58e9 -> 0x0000 DP 1 Data: 000502000400000001
Frame 2067 at Mar 31, 2022 11:24:21.183943000 CEST 0x0000 -> 0x58e9 DP 109 Data: 00
Frame 2071 at Mar 31, 2022 11:24:21.291195000 CEST 0x58e9 -> 0x0000 DP 108 Data: 00
==> frost status DP 108, reset with DP 109.
Offtopic: Does anyone know if this valve is available somewhere? In the Lidl webshop the item is already out off stock for almost a year... Is it available in the store itself?
@FutureCow I think it will be available in a month - season has not yet started, maybe this is the reason of empty stocks
Offtopic: Does anyone know if this valve is available somewhere? In the Lidl webshop the item is already out off stock for almost a year... Is it available in the store itself?
there was a guy selling them on ebay UK, i bought four about a month ago, but he still had plenty of stock:)
At least in Portugal they will be out for sale next week
Oh my god! So many new options 🚀 🤣
It looks very promising! I created a gist to share my latest code, until it's ready for an official PR: https://gist.github.com/zinserjan/e0486af73d0aa8c6aeed31762e831022
What's working:
Issues:
In addition to that I have some questions for the owners of the original ZB gateway & app:
UPDATE: Resolved the issue with the time sync. Time sync needs to start from 1970. NOTE: Make sure that you rejoin the device to force a new time sync.
Oh my god! So many new options 🚀 🤣
It looks very promising! I created a gist to share my latest code, until it's ready for an official PR: https://gist.github.com/zinserjan/e0486af73d0aa8c6aeed31762e831022
What's working:
- On/off state reporting
- Frost alarm & reset
- Reading & setting time slots (tested only slot 1 & 2 atm, but the others should work too)
- Reading & setting automatic watering schedule in weekday mode (Monday - Sunday)
- Reading & setting automatic watering schedule in periodic mode by day interval
- Reporting of remaining time when watering is triggered by automatic schedule via workaround (unfortunately there are no messages from the device for this)
Issues:
- ~Weekday watering is sometimes not working. It seems that the date & time sync is kind of broken. The watering time slots are always scheduled correctly in all day mode, but for single days it's kind of luck. I got it working several times today, but when I rejoined the device, which results in a new time sync, there was a high chance that the day mismatches (+- 1-2 days)...~
- There is no initial reporting of the frost alarm state. That's why I trigger the reset action & alarm state when the device joins the zigbee network. I don't like it but this ensures that the device will work and reports correctly after adding it.
- Frost alarm will never report again and activate the frost guard, when there is a reset and the device stays in the freezer (not really sure about that, tested it only for an hour).
In addition to that I have some questions for the owners of the original ZB gateway & app:
- Is it possible to disable periodic or weekday watering in the app without touching the enabled state of the time slots? Would be nice to get another sniff if this is possible.
How does the periodic watering mode work and which settings are possible? Especially:
- I noticed that it will start from today if I set it to an interval of 2 days. In my opinion it should then run today, pause one day and start again with this setting (every 2nd day). Is my assumption right?
- What are the min and max values for the day interval? In theory I could configure that it should only water every 30 days. Is that also in the app possible? Personally, I'm very interested in the min value, cause I tested it with value 0 and 1 and saw no difference for today. Initially, I thought that an interval of 0 would disable it..
UPDATE: Resolved the issue with the time sync. Time sync needs to start from 1970. NOTE: Make sure that you rejoin the device to force a new time sync.
Thanks!!! it works, but how you can set timer or change another settings from ha? i've also tried change timer from z2m web interface but no success.
I just updated parkside-watering-timer.js to the latest one and restarted Z2M. I can see that frost alarm is ON (it's 2.5C outside). I reset it yesterday and it was OFF so maybe there is some delay before it goes back to ON. Maybe update of the file had influence on it, not sure. I didn't repair devices (I have 2). Another thing, there is no entity to reset the frost alarm. The only way is to do it via Z2M interface.
I just updated parkside-watering-timer.js to the latest one and restarted Z2M. I can see that frost alarm is ON (it's 2.5C outside). I reset it yesterday and it was OFF so maybe there is some delay before it goes back to ON. Maybe update of the file had influence on it, not sure. I didn't repair devices (I have 2). Another thing, there is no entity to reset the frost alarm. The only way is to do it via Z2M interface.
i had also the frost alarm on in one and its also 4C degrees.
Dear all, I tried to create support for the Parkside Smart Watering Timer, but failed catastrophically :)
I created a .js file for Tuya like explained in the tutorial - but then Z2M will not start anymore. I copied the content on the bottom of the message. If anyone is willing to help, I'd highly appreciate.
Thanks and best regards
Information about the device + link
Parkside Smart Watering Timer https://www.lidl.de/de/parkside-smarter-bewaesserungscomputer-zigbee-smart-home/p375570
Failure message when starting Z2M
[08:04:41] INFO: Handing over control to Zigbee2mqtt Core ...
PSBZS.js
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 e = exposes.presets; const ea = exposes.access;_
const definition = { fingerprint: [ { modelID: 'TS0601', manufacturerName: '_TZE200_c88teujp' }, ], model: 'PSBZS A1', vendor: 'Lidl', description: 'Smart Watering Timer', supports: 'thermostat, temperature', fromZigbee: [ fz.ignore_basic_report, // Add this if you are getting no converter for 'genBasic' fz.tuya_data_point_dump, // This is a debug converter, it will be described in the next part ], toZigbee: [ tz.tuya_data_point_test, // Another debug converter ], onEvent: tuya.setTime, // Add this if you are getting no converter for 'commandSetTimeRequest' configure: async (device, coordinatorEndpoint, logger) => { const endpoint = device.getEndpoint(1); await reporting.bind(endpoint, coordinatorEndpoint, ['genBasic']); }, exposes: [ // Here you should put all functionality that your device exposes ], };
module.exports = definition;
Edit: Link to Zigbee Alliance https://zigbeealliance.org/zigbee_products/smarter-water-computer/