DDF - Add GiEXperience SMART Water Valve #6947
Conversation
Fix DDF validation errors.
|
Hey @BEskandari, thanks for your pull request! Tip Modified bundles can be downloaded here. DDF Bundles changesModified
ValidationTip Everything is fine ! 🕞 Updated for commit 5963c4c |
|
Well, it's a little bit mixed up for my personal taste and somehow a good example that even the best attempts for reasonable recycling of resource items can hit the limits quite quickly. Strickly speaking, items and device types available do not really fit the device at hand. Not sure if a 0x0702 consuption devices would be expected by anyone here 🤔 Tricky... |
| "default": 0 | ||
| }, | ||
| { | ||
| "name": "config/duration", |
There was a problem hiding this comment.
I don't think we have anything for last irrigation duration. I don't think it should be on the sensors resource, but on the lights resource instead, where you handle the on/off state. Also, it should be a state item, as it's not configurable.
There was a problem hiding this comment.
The DDF was created through @BabaIsYou advice (see #6944). I was able to make the device working (on/off) and have added also some printscreen of eve app on the issue request.
There was a problem hiding this comment.
I see I'm already quoted on that issue.
To get remaining duration in Eve (and even in Apple's Home app), expose the device as a Valve accessory. Homebridge deCONZ does expect state/ontime to support that, though. Never tried to combine that with consumption, though.
| } | ||
| }, | ||
| { | ||
| "name": "state/consumption", |
There was a problem hiding this comment.
Using ZHAConsumption's for water consumption (rather than electricity) is new for me, but seems logical. However, I don't think it's a good idea to abuse state/consumption. Instead, we should be using state/measured_value and the corresponding cap items to indicate the substance (water), quantity (volume), and unit (litres or m3?), as well as min/max values.
Typically state/consumption reports the life time consumption (since last factory reset), not the consumption during last run.
| "fn": "tuya" | ||
| } | ||
| }, { | ||
| "name": "config/mode", |
There was a problem hiding this comment.
config/mode (and similar like config/devicemode etc) is becoming a nightmare. I think we really need a cap resource to list the possible modes (value and description?).
| "name": "state/lastupdated" | ||
| }, | ||
| { | ||
| "name": "config/delay", |
There was a problem hiding this comment.
Using config/delay for a cycle interval doesn't seem right. Closest we have resembling this is the schedule on thermostats, but that's way too elaborate for this.
| } | ||
| }, | ||
| { | ||
| "name": "state/seconds_remaining", |
There was a problem hiding this comment.
We expose (writeonly) state/ontime on lights resources to set the target "duration" for the light to be on (this sends an On with Timed Off command). I think that could be used here, to set the irrigation duration, but it should be on the On/Off Output lights resource.
We don't (yet?) expose the OnTime attribute (the currently remaining "duration", which counts down to 0s, before the light turns off). The issue is that it's not reportable and there's no way to force the API to issue a Read Attributes right now, so the value will always be outdated hopelessly (by minutes at least). Unless the water valve sends push notifications for the remaining time, it doesn't make sense to expose seconds_remaining. Also, it should be exposed on the lights resource, because that's where you control the on/off state. Maybe expose the expected end time instead? Although, we don't have anything for that either.
close #6944