Many devices got a lot of parameters to adjust, and it’s easy to overlook something. It would be a great idea to have a feature to say “make these parameters the default” for that device type when openhab discovers a new thing of that same type.
This is mostly up to people to modify the database. For those devices where I have found good default values, I have tried to include them in the database entry description along with what the default setting is. If there are particular devices that you find settings for that would be handy for most users of the device with OpenHAB, you can either request access to the database from @chris, or let someone that does have that access know so they can make changes for you. I’d be happy to help.
Aha. I just had some trouble figuring out some parameters for the Fibaro Dimmer 2 (FGD212) in direct association with a remote. I guessed somebody else already had done this if it was possible. The documentation is quite comprehensive, but doesn’t say much about “if you want this, then do like that…”.
When dimming up and down using long press, the light instantly went from 0 to 100 and vice versa. It didn’t seem like it was dimmed at all, just simple on/off. The key was to change “8: Dimming Step Timing at Manual Control” from 1 ms to for example 5ms, or else it all happened too quickly to stop at something in between 0 and 100.
I agree!
Something I’ve thought of, is to add a ‘configuration set’ feature to the database. It would allow people to define parameter configurations, associations etc, and then in HABmin we have the option to select a configuration set. This would allow different configurations to be defined to support different setups…
Like everything, it’s about time, and this idea hasn’t quite made it up the list…
Actually, I see in the Fibaro documentation for FGD-212 that Parameter 8 has a default value of 5, but in our database it is 1. Setting it to 1 will make dimming in direct association from a remote more or less useless. It should probably be changed.
I updated the entry. Happy to do more if you find them, but it also looks like somebody that has that device or the time should go through and fix the descriptions. Many are too long so the user experience setting the device up will be diminished.
Thank you so much!
I’m also testing a thermostat from Thermo-Floor with model number TF016 (Multireg). It should be the same as the HeatIT-thermostat (TF021). However, configuration parameters are completely missing from openhab2/habmin2.
The device also do not have the correct channels defined. It has different setpoints for each mode (Heat, Heat Eco, and so on), but only “Heat” seems to be implemented. Also, the “sensor_temperature” get updated with the setpoint value. I’m a little bit lost, but I’d be happy to investigate more if you’ve got some hints 
Note that the binding doesn’t automatically change any parameters. The default setting in the database is there for information - the binding won’t change it (currently anyway) unless you manually set it to something in the UI.
That’s not to say the database shouldn’t be correct, so if you find errors, please update it.
Is the device in the database at all? If not, then it should be added.
If it is, and it has exactly the same parameters as another device, then we can copy the device information easily.
It seems to be in the database, but I wonder if something is incorrect and/or missing.
According to some other forum posts, there might be multiple instances on this. But openhab2 doesn’t know about these?
openzwave has implemented the configuration parameters (heatit21 and tf016 should be the same), and I see that the setpoints for CO en ECO mode are implemented as configuration parameters on instance 1?
Anyway, as I mentioned in my last post. The sensor value which should get the air temperature gets updated with the setpoint of the thermostat instead. I’ve sent an email to support, but are there a small chance that this is openhabs fault?
Have you checked the device IDs in the database are the same as your unit? Many manufacturers use multiple sets of IDs for different regions, or whatever, so you need to check this to be sure that YOUR device is in the database.
It seems to be the same as the database?
from debug log:
NODE 15: Manufacturer ID = 0x019b
NODE 15: Device Type = 0x0001
NODE 15: Device ID = 0x0001
database:
Manufacturer Thermo-Floor
Manufacturer ID 019B
Name TF016
Device Description ZWave Thermostat
References (Type:Id) 0001:0001
What’s the best way to test changes to this? Unpack jar file, change files, repack and restart openhab? Is it then enough to delete the thing, or is a complete re-inclusion necessary?
Ok, so looking at the database, there are no configuration parameters currently added, so this would explain the issue. If you want to add them, it would be the quickest way to change this .If you don’t have an account, please create one and let me know so I can give you edit rights.
My username is mtryfoss
After a database change I will need a complete build environment (not into Java) to test it, or will it be there in the next nightly?
It will be deployed into the next nightly.
I’ll give you access to the database when I get home (around 1800 CET).
Thank you.
I’m also wondering if this device has changed and got new features in firmware 1.8. How do we deal with this? I don’t want to mess up anything for other users holding earlier models.
I also tested it in openhab1 on the same machine/controller, and that produced an xml file containing some other information. For example an extra setpoint entry in OH1 (HEAT_ECON), different version for SENSOR_MULTILEVEL (5 in OH1, 6 in OH2). Is this relevant at all, regarding the fact that the unit seems to not work as intended?
The database contains separate entries for devices that have different configurations. We can set the version number in the database, and the binding will use the appropriate version. If the features have changed, then we will therefore need to duplicate the entries, and set the version number ranges.
So, the XML file should contain the results of the device scan. The device should describe what setpoints it supports - if someone has uploaded their XML file from one version, and the new version now supports more features, then we need to update (same point as above).
Well, I guess we need to get the database correct so that it does work as intended 
You should now have access to edit the database - any problems, just let me know.
Cheers
Chris
Thank you!
I also see that in the manual for the device it specifies SPECIFIC_TYPE_SETPOINT_THERMOSTAT but the database (and in the discovered xml) is THERMOSTAT_GENERAL_V2. Should I try to use what specified in the manual?
These classes are mentioned:
GENERIC_TYPE_THERMOSTAT
SPECIFIC_TYPE_SETPOINT_THERMOSTAT
COMMAND_CLASS_BASIC
COMMAND_CLASS_THERMOSTAT_SETPOINT_V3
COMMAND_CLASS_THERMOSTAT_SETBACK
COMMAND_CLASS_SENSOR_MULTILEVEL
COMMAND_CLASS_VERSION
COMMAND_CLASS_MANUFACTURER_SPECIFIC
COMMAND_CLASS_ASSOCIATION
No - please don’t mess with this. This information is read directly from the device so it will be correct. The name might be different than used in official documentation, but the value, which is the important thing, will be correct.
I’ve uploaded the xml now without any more changes.