There’s nothing to click the only option there is “Disable” like in the screenshot for 3 parameters 62, 64, 66 where the bigger issue is that default parameter 66 of 3600 is not accepted at all and thing cannot initialize, I don’t think this is an issue with UI, as I understand actual binding handles this (I’ve hacked mine). Also parameter 154 is incorrect - it is cumulative parameter for 4 inputs but because one option specified it shows “on” for input 1 and 255 for 3 others without possibility to change it.
Latest release “3.3.0 - Release Build”, I can try latest RC to see if anything changed in that.
Absolutely agree, I will restore options in DB. But we need to get to the root of this, it looks like a serious issue. Let me know how I can help.
No - the binding doesn’t manage this as such - these checks are handled in the core.
Well, I’m really not sure what’s happening. If I look at the definition in the binding for this parameter, it should be ok -:
<parameter name="config_66_2" type="integer" groupName="configuration">
<label>66: Energy report frequency</label>
<description><![CDATA[
Energy report frequency<br /> <h1>Overview</h1><p>Choose how often you want your RGBW Dimmer to report energy (kWh) to your controller. The number entered as value corresponds to the number of seconds. So if 3600 is entered by default, the RGBW Dimmer will report energy use every hour(independent of the threshold set in parameter 65). Energy reports are sent in at least 30-second intervals.</p> <p>Allowed values: 0 (disabled) or 30 - 32400 seconds</p> <p>Default: 3600 seconds (1 hour)</p>
]]></description>
<default>3600</default>
<options>
<option value="0">Disable</option>
</options>
<limitToOptions>false</limitToOptions>
</parameter>
It has limitToOptions set to false, so the core should allow a value of 3600. There is no min/max set (I’m not sure why that is, but the docs state that this is optional, so I would expect that ANY value should be accepted.
I would suggest to provide the log showing what is happening as the core should log the validation error.
@J-N-K any thoughts - I would guess that there’s a bug in the validation code. Possibly the fact that min/max aren’t there is causing the validation to misbehave?
If the default for 66 is failing, then that is a bug, but IIRC there is a test that ensures it is working. Is 62 (which I understood is the issue here) defined the same way?
(Sorry for the confusion) Parameter in question which failed validation is 62, same as TC had issues with and Default from documentation and from the device I’ve got is 3600 which was not accepted, according to log attached the only option for this parameter allowed is 0. I can change this in DB to 3600 and return option “0” - “Disabled” but the question still why UI / Core is not honoring “false”
Just so to add to the confusion: as my log showing my device come with Default Parameter 66 set to 0 however docs saying it should be 3600 and that was allowed value and it didn’t failed in my case, go figure.
I’ve added: Option “0 - Disabled” for parameters 62, 65, 66; Changed default for 62 to 3600 and set “LimitToOptions” for Parameter 65 to false. Requested review.
What is failing: UI is ignoring “false” and allowing only to set Parameter to value provided in “Option”, for ZEN31 device this is failing for Parameter 62 which by default coming with 3600 but DB saying only 0 is allowed.
{config_62_2=The value 3600 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Disable”]]}
This was the problem. As I noted above the device DB was updated after the release on July 9 and why this thread was marked “solved”
Look at the very first post in this chain and compare to your post directly above this one. The 3.3 release had the flag set as true for config_62_2 and @chris changed to false in the second post of the chain (effective with the July 9 snapshot). There is no UI problem.EDIT (at least related to config_62
So the issue was present in 3.3 release but has been fixed later by updating the DB. There is neither a validation issue in core nor an UI issue, correct?
This am (my time) I went through the Zen31 DB config and restored the configuration back to what was reported working earlier (with the exception I left the change to 3600 as default on config 62_2. I could quibble with config 154_2, 154_3 and 154_4, but I also left them how they were working (i.e. passing the validation) before.
The only issue I can see is that the Zen31 was dropped from the latest DB update and with @chris travelling for his real job, the next 3.4 milestone will not have this device. I’m assuming the milestone will be after the August, but before Octoberfest
I leave tonight so I’ll try and do another update. I’m travelling mostly for holiday - the first 2 weeks are in Africa and after the first couple of days we will likely have no internet. After that I’m in the UK for work/holiday and should have occasional access so will try and do another update then.
No, nothing like this. I use 3.3 release and just changed XML for the node from 3600 to 0, restarted the binding and it passed validation. No code change or anything like this.
