Closed drdownload closed 3 years ago
Hi @drdownload ,
Since the very beginning of using this external converter (regardless of the converter's version) I get following:
Please, kindly advise, if those five red error logs from the above screen which relate to zigbee-herdsman are important from the converter's perspective and I'm doing something wrong, or they may be ignored? I have no clue how to resolve this issue if this is really an issue.
I'm asking for the advise, since after zigbee2mqtt add-on starts, the Zigbee Devices List is being displayed correctly and all their entities are fully available and visible on my dashboard:
This error is regarding problems opening the zigbee usb device.
I have only one USB device in my zigbee network, which is ConBee 2 Zigbee USB-Gateway from Dresden Elektronik, plugged into USB port of HA server and fully configured as per documentation. Moreover, thanks to this device I'm able to join all the zigbee devices to my zigbee network (see previous screen). If this error is being caused by ConBee 2, I wouldn't be able to see any zigbee devices on my dashboar, right? But I see them all. If the above red error log is regarding problems opening zigbee usb device, maybe I should simply ignore it, since I have no other USB devices in my zigbee network, except this one Conbee 2.
Hey guys,
I've uploaded my version of the gist: https://gist.github.com/geoffreylagaisse/bb90214dbaf687465e5841f49685cf66
Biggest differences from @drdownload is that the heatstopping & away/holiday mode (by using the system_mode off or holiday preset) are working. I'm also using a few more standard variables of zigbee2mqtt. The frost protection and heatstopping boolean are still giving a publish error when I try to change them, still working on that.
Should this converter work for this device? https://www.zigbee2mqtt.io/devices/GS361A-H04.html
Because i get the same error: The manufacturer name from: Device with modelID 'TS0601' is not supported.
Can someone help me where to put the js file in the zigbee2mqtt container?
The JS converter should be copied to config/zigbee2mqtt folder of your HA instance. Then you have to configure its appearance in zigbee2mqtt add-on. Personally I doubt if this converter will work with the valve you use, since it's dedicated for another device series (TS0601).
@mullischlumpf : If your TRV looks like the one in the link it should work with stock zigbee2mqtt. In your zigbee2mqtt Log look for the following string Received message from unsupported device with Zigbee model 'TS0601' and manufacturer name '_TZE200_hhrtiq0x' or open the webinterface to look up the manufacturer name. Search for this string to get help.
Hey guys,
I've uploaded my version of the gist: https://gist.github.com/geoffreylagaisse/bb90214dbaf687465e5841f49685cf66
Biggest differences from @drdownload is that the heatstopping & away/holiday mode (by using the system_mode off or holiday preset) are working. I'm also using a few more standard variables of zigbee2mqtt. The frost protection and heatstopping boolean are still giving a publish error when I try to change them, still working on that.
Big thanks for supporting this converter, I'm only learning and I dont have a lot time to spare. Quick question: is tuya or localTuya correct in the highlighted spots? (since youre calling zsXX Dp)
@drdownload apparently I made some typo's. In this case it should have been localtuya. This could be why I'm receiving publish errors while calling the function 😂 nice find
I've updated my gist again, frostprotection and heat stopping booleans are now working. I've also corrected the dp's @drdownload mentioned.
Device has just been added in https://github.com/Koenkk/zigbee-herdsman-converters/pull/3185
Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html)
@geoffreylagaisse : I saw you did some work on the official converter, I just tried it with one of my TRV. Removed it and added it again to flush wrong states and history.
But a lot of stuff seems not work like child lock that worked on the external converter
Also the errors when adding with unsupported datapoints also show up.
hmmm @drdownload I will have a look at it this evening. I specifically looked at the preset and mode code, not at the rest the other dev has written. I'll keep you updated with my progress.
No worry/hurry, I'm just curious ;) - also I now got my Tuya Zigbee hub to try to debug missing stuff (I just need to figure out how ;) )
@drdownload I found the reason why ;-) https://github.com/Koenkk/zigbee-herdsman-converters/pull/3224 They where using enums instead of booleans.
@drdownload new PR has been merged and will be available shortly in the edge version. If you have any other issues, you may contact me on discord with the handle: geoffreylagaisse#3883
@geoffreylagaisse : thx a lot. I'll try it. I think only thing I need to find out is why the local_temperature wont get updated, I assume, the tuya hub (which get updates) has a command to query for an update)
maybe I have time to get into zigbee sniffing on the weekend (I have paired the least important TRV with the tuya hub)
@drdownload I've just checked something. The IS_online datapoint (115) is set able. When using the boolean we are receiving a complete update. Also for the local temperature. You see the drop after I triggered the is_online boolean
Wow, that's nice find, is there a way to integrate in the converter to check is online every x minutes? A quick google search did turn up only the availability feature but I assumr this won't send this online datapoint
On Wed, 27 Oct 2021, 17:55 Geoffrey Lagaisse, @.***> wrote:
@drdownload https://github.com/drdownload I've just checked something. The IS_online datapoint (115) is set able. When using the boolean we are receiving a complete update. Also for the local temperature. [image: image] https://user-images.githubusercontent.com/51802836/139102033-530da067-215b-4d71-ae10-a2fe5650d797.png You see the drop after I triggered the is_online boolean
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/8522#issuecomment-953066885, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKYGOK2CGWJPBGALXI2KLLUJAVHNANCNFSM5CZS5YRA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I integrated an crude method to set the DP isOnline in my converter, but there must be a better way ;)
Also this triggers an update for a lot of stuff fmpov window_mode away_mode week/day schedule
yeah The is online contains a complete update. I've updated my Gist again and added it to the state get of the local temperature. Maybe there is a special way of triggering the get every once in a while, still figuring this out.
Boost is also working, but gives an input error when you just triggered it.
I now update via an home assistant automation. @geoffreylagaisse thanks for your support, without it I would be sitting on a bunch of electronic junk (ok thats too much)
Glad to help, I'll add the rest of the goodies to the official code this evening.
Glad to help, I'll add the rest of the goodies to the official code this evening.
I have seen your work and I can say that theyour variant is more suitable. You can change completely as is in the file.
geoffreylagaisse/TV01-ZG.js
I also worked on the local converter for TV02-ZG and therefore also have ideas for fine tuning. I'm glad to help too.
This is the case with TV02-ZG in manual.
Is the same for TV01-ZG in manual? Or other?
If the same, then the battery level display does not have to be a percentage.
battery_low = ON / OFF
@vladi1234 In our case the device reports the complete battery status. But I've yet to find how I can poll the individual datapoints. We now know that triggering the is_online datapoint gives us a complete status update, but this shouldn't be the way to go.
where can I find your code?
@geoffreylagaisse My complete code looks unsightly, I haven't cleaned it up, so I haven't put it out.
case tuyaLocal.dataPoints.tvBattery:
return {battery_low: value === 0 ? true : false};
With my TV02-ZG is_online delivers data when I press OFF.
As for the query, see the example from and down this line: configure: async (device, coordinatorEndpoint, logger) => {
const exposes = require('../lib/exposes');
const fz = {...require('../converters/fromZigbee'), legacy: require('../lib/legacy').fromZigbee};
const tz = require('../converters/toZigbee');
const ota = require('../lib/ota');
const constants = require('../lib/constants');
const reporting = require('../lib/reporting');
const e = exposes.presets;
module.exports = [
{
zigbeeModel: ['SPZB0001'],
model: 'SPZB0001',
vendor: 'Eurotronic',
description: 'Spirit Zigbee wireless heater thermostat',
fromZigbee: [fz.legacy.eurotronic_thermostat, fz.battery],
toZigbee: [tz.thermostat_occupied_heating_setpoint, tz.thermostat_unoccupied_heating_setpoint,
tz.thermostat_local_temperature_calibration, tz.eurotronic_thermostat_system_mode, tz.eurotronic_host_flags,
tz.eurotronic_error_status, tz.thermostat_setpoint_raise_lower, tz.thermostat_control_sequence_of_operation,
tz.thermostat_remote_sensing, tz.thermostat_local_temperature, tz.thermostat_running_state,
tz.eurotronic_current_heating_setpoint, tz.eurotronic_trv_mode, tz.eurotronic_valve_position],
exposes: [e.battery(), exposes.climate().withSetpoint('occupied_heating_setpoint', 5, 30, 0.5).withLocalTemperature()
.withSystemMode(['off', 'auto', 'heat']).withRunningState(['idle', 'heat']).withLocalTemperatureCalibration()
.withPiHeatingDemand(),
exposes.enum('trv_mode', exposes.access.ALL, [1, 2])
.withDescription('Select between direct control of the valve via the `valve_position` or automatic control of the '+
'valve based on the `current_heating_setpoint`. For manual control set the value to 1, for automatic control set the value '+
'to 2 (the default). When switched to manual mode the display shows a value from 0 (valve closed) to 100 (valve fully open) '+
'and the buttons on the device are disabled.'),
exposes.numeric('valve_position', exposes.access.ALL).withValueMin(0).withValueMax(255)
.withDescription('Directly control the radiator valve when `trv_mode` is set to 1. The values range from 0 (valve '+
'closed) to 255 (valve fully open)')],
ota: ota.zigbeeOTA,
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
const options = {manufacturerCode: 4151};
await reporting.bind(endpoint, coordinatorEndpoint, ['genPowerCfg', 'hvacThermostat']);
await reporting.thermostatTemperature(endpoint, {min: 0, max: constants.repInterval.MINUTES_10, change: 25});
await reporting.thermostatPIHeatingDemand(endpoint, {min: 0, max: constants.repInterval.MINUTES_10, change: 1});
await reporting.thermostatOccupiedHeatingSetpoint(endpoint, {min: 0, max: constants.repInterval.MINUTES_10, change: 25});
await reporting.thermostatUnoccupiedHeatingSetpoint(endpoint, {min: 0, max: constants.repInterval.MINUTES_10, change: 25});
await endpoint.configureReporting('hvacThermostat', [{attribute: {ID: 0x4003, type: 41}, minimumReportInterval: 0,
maximumReportInterval: constants.repInterval.MINUTES_10, reportableChange: 25}], options);
await endpoint.configureReporting('hvacThermostat', [{attribute: {ID: 0x4008, type: 34}, minimumReportInterval: 0,
maximumReportInterval: constants.repInterval.HOUR, reportableChange: 1}], options);
},
},
];
@vladi1234 How dit you retrieve the report ID's and the manufacturerCode? I need to do the same for my current temperature datapoint. 0x0218
@vladi1234 , can you post an link to the tv02?
Another question to @geoffreylagaisse: maybe we could document somewhere the steps/tools needed to come that far (eg. first the DP + what they are for etc.)
@geoffreylagaisse Tuya manufacturerCode: 0
@vladi1234 @geoffreylagaisse @drdownload
Sorry if I'm stupid but whats the current state of this all being merged?
is_online and most features are missing from the latest edge version from 4 days ago ... from how I see it (by testing myself)
Where do you all push your code? Branches? Is it only on the dev-branch here? Tried to look but found nothing that would point me in the direction ... its like search for a needle in the haystack.
Especially the features from @vladi1234 look interesting but hardly usefull to tackle if you never push it anywere not matter if its ugly or not ... would be very cool of you if you could share it!
Most of the code has been pushed to https://github.com/Koenkk/zigbee-herdsman-converters
The only change I have still open is the is_online (https://github.com/Koenkk/zigbee-herdsman-converters/pull/3247). Rest of the functionality has been merged via PR. The code from @vladi1234 is from another device and he just shares his own experience. I have bought myself a Tuya hub to go after the manufructurer code so I can speak and catch with the reporting endpoints. The Tuya hub does something different then we do. Triggering the is_online is one option, but an ugly one ... The device lights up for a minute and drains the batteries. So I guess my answer is, it is still under investigation.
I already finished my TV02-Zigbee TVR and it works properly. You can already see the z2m dev branch and look a lot better than before. I have described quite a lot here: https://github.com/Koenkk/zigbee-herdsman-converters/issues/3142#issuecomment-962460788
@geoffreylagaisse I also tested your is_online function. According to my experience of the is_online function, it looks like that is_online only does reboot TVR and of course delivers all data new. But this is not a good solution to get the current local_temp. @geoffreylagaisse is_online funktion hat kein Sinn. It makes baterry kapput. I have found another solution for how to get local_temp, it is much more simple and baterry-friendly. You can read this here: https://github.com/Koenkk/zigbee-herdsman-converters/issues/3142#issuecomment-976885156
Many thanks for the explanation.
@vladi1234 I just tried that myself regarding local_temperature_calibration - it also does wake the device up and light up the screen so it should have the same effect I guess on the batteries .. however I'm using the MOES branded variant of that so I wonder if that's behaving any different ...
I do have a spare valve and a Tuya hub laying somewhere around ... maybe I should look into that too ... I wonder if there's any way to disable the screen from waking up.
@vladi1234 Are you sure about the reboot by "is_online". I run this code (ok, an custom version but essentially the same) for a month and if the battery reporting is correct still no impact on battery life. I call the is_online every 15 minutes.
The device lights up for a minute and drains the batteries.
Funny, mine dont do that or I never noticed (they are at my holiday home, so I cant check quickly)
with my TV02-Zigbee _TZE200_hue3yfsn is as I wrote, TVR vehält itself quite , without a display light up.
_TZE200_e9ba97vf is the Moes branded variant too - so both TV01-ZG and TV01-ZB seems to behave the same in regards to the screen waking up ... however I didnt try the is_online hack myself ... only the local_temperature_calibration yet
The device lights up for a minute and drains the batteries.
Funny, mine dont do that or I never noticed (they are at my holiday home, so I cant check quickly)
@drdownload As far as battery is concerned, I already wrote above why nobody notices that the battery is empty? Because my TVR has two states 0 and 100, and not procentual! and at 12% jumps to 0.
https://github.com/Koenkk/zigbee2mqtt/issues/8522#issuecomment-955747634
Are you sure about the reboot by "is_online".?
If you use is_online, TVR delivers many error messages, whether reboot, complete initialization or reset happens.
If you take the battery out and reinsert it, then the installation process starts and then TVR does exactly that itself like is_online.
I saw the same behaviour (lots of unknown datapoints) but I assume thats a complete update and not all DP are implemented in the converter (e.g. weekday-programm) so it would lead to unkown DP messages.
With my TVR, all DP and weekday programs are known, but there are still various errors.
I ordered some more TRV01, when they arrive I can also look into this more. I need to look up a tutorial to sniff traffic between the tuya gateway and the TRV
@drdownload no actually he is right these messages seems to cause the device to drop from the hub - I just tested that ... ours seems to "only" disconnect. Interestingly you dont notice it unless you manually pair them again.
The device I tested this on is far away from the repeater or hub and has a lqi of just 9 so maybe it has something to do with it.
What I did was set the temp in manual mode on the valve itself to 24, temp reading was like 21,9 then I set calibration to -0,7, the valve motor seemed to spin for 0.5s then rapidly stopped, the bunch of error messages about unkown dps appeared and afterwards it was disconnected.
LCD didnt light up when the unkown dps happened mind you.
Hmm, very strange. Its really a shame my trv01 are 200km away. I trigger every 15 min. this DP
For weeks everything is working. I get my temp updates and setting the target temp worked. (i use only manual mode, the rest is done by home assistant) While I was there I would have never noticed the lights/display of the TRV set on.
Hmm, very strange. Its really a shame my trv01 are 200km away. I trigger every 15 min. this DP
For weeks everything is working. I get my temp updates and setting the target temp worked. (i use only manual mode, the rest is done by home assistant) While I was there I would have never noticed the lights/display of the TRV set on.
target temp or local_temperature_calibration?
Sorry, I meant setting the target temp for heating with current_setpoint and watching the temperature actually rise in the room ;)
So after pairing this specific one again the lqi is back to 51 and it works like just before.
I have a bunch of them and this one displayed the year 2020 on the Initial setup - others did display 2021 to being with, without ever being paired by myself - so there must be different firmware revisions.
I will try to pair this one in specific to Tuya and see myself.
fromZigbee.moes_thermostat_tv: NOT RECOGNIZED DP 115 with data {"status":0,"transid":158,"dp":115,"datatype":4,"fn":0,"data":{"type":"Buffer","data":[1]}}
fromZigbee.moes_thermostat_tv: NOT RECOGNIZED DP 113 with data {"status":0,"transid":157,"dp":113,"datatype":0,"fn":0,"data":{"type":"Buffer","data":[36,0,170,72,0,210,84,0,170,102,0,210,144,0,170,144,0,210,144,0,170,144,0,210,144,0,170,144,0,210]}}
fromZigbee.moes_thermostat_tv: NOT RECOGNIZED DP 109 with data {"status":0,"transid":156,"dp":109,"datatype":0,"fn":0,"data":{"type":"Buffer","data":[36,0,170,72,0,210,84,0,170,102,0,210,144,0,170,144,0,210,144,0,170,144,0,210,144,0,170,144,0,210]}}
fromZigbee.moes_thermostat_tv: NOT RECOGNIZED DP 112 with data {"status":0,"transid":155,"dp":112,"datatype":0,"fn":0,"data":{"type":"Buffer","data":[36,0,170,72,0,210,84,0,170,102,0,210,144,0,170,144,0,210,144,0,170,144,0,210,144,0,170,144,0,210]}}
fromZigbee.moes_thermostat_tv: NOT RECOGNIZED DP 111 with data {"status":0,"transid":153,"dp":111,"datatype":0,"fn":0,"data":{"type":"Buffer","data":[36,0,170,72,0,210,84,0,170,102,0,210,144,0,170,144,0,210,144,0,170,144,0,210,144,0,170,144,0,210]}}
fromZigbee.moes_thermostat_tv: NOT RECOGNIZED DP 108 with data {"status":0,"transid":154,"dp":108,"datatype":0,"fn":0,"data":{"type":"Buffer","data":[36,0,170,72,0,210,84,0,170,102,0,210,144,0,170,144,0,210,144,0,170,144,0,210,144,0,170,144,0,210]}}
Edit: Ah here we go found my Tuya Zigbee Gateway ...
If you have a TRV01 these datapoints are: 108 = Monday Program 109 = Wednesday Program 111 = Sunday Program 112 = Tuesday Program 113 = Thursday Progam 115 = is_Online
at least the program DP are not implemented. why you get an error for 115 I dont know. But as I said Im using my own converter with some changes of geoffreylagaisse backported to it. never upgraded to this gist or the dev branch.
I found some bugs in Geoffreylagaisse code. You can test the code from my TV02 Zigbee. They seem to be compatible.
Sorry, @Geoffreylagaisse I didn't mean anything bad.
If that works, then I can put the two together.
Information about the device + link
Bought from this Link: https://de.aliexpress.com/item/1005002377522262.html?spm=a2g0s.9042311.0.0.4d6f4c4dEXD4cF
Found this Listing with reverse image search: https://expo.tuya.com/product/600974
data/database.db entry of the device
{"id":27,"type":"EndDevice","ieeeAddr":"0x84fd27fffe2dd98b","nwkAddr":18218,"manufId":4098,"manufName":"_TZE200_e9ba97vf","powerSource":"Battery","modelId":"TS0601","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":81,"inClusterList":[0,4,5,61184],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"modelId":"TS0601","manufacturerName":"_TZE200_e9ba97vf","powerSource":3,"zclVersion":3,"appVersion":69,"stackVersion":0,"hwVersion":1,"dateCode":""}}},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":69,"stackVersion":0,"hwVersion":1,"dateCode":"","zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":1629911314030}
Things I tried
I tried to add an external converter following the tuya specific guide.
first I tried with the default code from: https://www.zigbee2mqtt.io/how_tos/how_to_support_new_tuya_devices.html
then I copied the converter from the herdsman code that handles radiator thermostats and added the fingerprint.
however it always stays unsupported. I used this fingerprints: default config: fingerprint: [ { // The model ID from: Device with modelID 'TS0601' is not supported // You may need to add \u0000 at the end of the name in some cases modelID: 'TS0601', // The manufacturer name from: Device with modelID 'TS0601' is not supported. manufacturerName: '_TZE200_e9ba97v' }, ], model: 'TV01-ZG', vendor: 'ZONNSMART',
and herdsman converters code; zigbeeModel: ['TS601'], fingerprint: [{modelID: 'TS0601', manufacturerName: '_TZE200_e9ba97v'}], model: 'TS0601_thermostat', vendor: 'TuYa',