luking-dev / webiopi

Automatically exported from code.google.com/p/webiopi
0 stars 0 forks source link

Wildcards in Config options #33

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Config options for devices allow setting of parameters like I2C slave address. 
(Currently) they have to be in the right order as they are used in __init__ of 
the device class. Sometimes lets say I want to change the 3rd parameter. In 
order to do this its also necessary to provide the 1st and 2nd parameter even 
if they can keep their defualt values. One possibility would be to copy the 
parameter=value scheme from __init__ into config. But that would be heavy 
additionally parsing effort.

A simple solution would be to allow e.g. "*" as placeholders for parameters 
that can keep their default values from __init__. The number/sequence of 
parameters will still have to be the correct one (trailing ones not nedded to 
be changed at the end can be ommitted), but errors arising from wrong 
hard-coded default values in config can be avoided.

Example

mydevice = DEVICECLASS * * 13

On implementation side, the code that scans config parameters could just pass 
"None" on all parameter positions that can keep default values so that the 
__init__ values provide the missing value again.

Original issue reported on code.google.com by andreas....@googlemail.com on 25 Feb 2013 at 11:34

GoogleCodeExporter commented 9 years ago
I would like a more explaining example with a specific device class for 
instance.

Original comment by tro...@trouch.com on 25 Feb 2013 at 1:41

GoogleCodeExporter commented 9 years ago
I checked VCNL, and I understand the problem...
First, are all arguments supposed to be tweak ?
Then, instead of using wildcard, we could use key/value pair :
light0 = VCNL4000 current=40
or
light0 = VCNL4000(current=40)

but I have to check how my config parser will handle multiple '=' in a line

Original comment by tro...@trouch.com on 25 Feb 2013 at 1:58

GoogleCodeExporter commented 9 years ago
Some more examples:

TMPx75:

mytmp = TMP75 * 10

Set the resolution to 10 bit but keeping the default slave address

If we (may) add setting the upper and lower alert/thermostat registers of them 
as parameter 3 and 4:

mytmpwithalerts = TMP75 * * 10 40

Set the temps to 10 deg low and 40 deg high but keep the default slave address 
and default resulution

TSL2561 with high gain:

mytslhighgain = TSL2561T * * 16

Original comment by andreas....@googlemail.com on 25 Feb 2013 at 2:04

GoogleCodeExporter commented 9 years ago
or 

light0 = VCNL4000 current:40 as the ":" may be free to simplify parsing

Original comment by andreas....@googlemail.com on 25 Feb 2013 at 2:09

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Well I tried the two options :

1) passing None to a function override defaults. So defaults values has to be 
handled manually in the code instead of __init__ declaration with wildcard 
support.

2) key/value pair args cannot be mixed with simple value args in config file. 
We always need to precise arg names.

giving this, I think opt. 2 is clearer and more consistent, so I committed in 
r976. I let you try with TMPx75 or VCNL before closing the issue.

Original comment by tro...@trouch.com on 25 Feb 2013 at 7:26

GoogleCodeExporter commented 9 years ago
I was able to test the new config option with tsl and vcnl and can confirm it 
working perfect ok. Thanks for updating. I was also able to test 
devices-monitor with all my sensors attached. See attached screenshots. This 
also confirms the distance part of the vcnl driver mapping correct for 
devices-monitor.

During my test I moved the vcnl adapter to another place on my breadboard and 
.... what a wonder .... it started working. Assume the breakout has a bad smd 
soldered chip that re-got the connection by moving. Not very solid as I moved 
the beakout also sometimes before and this did not help, but as long as it 
works now .... Anyway, that allowed me to final test also the distance part of 
the vcnl driver and tweak the distance lookup table a bit so that I can confirm 
now also the distance part of the vcnl driver to be final for now and tested. 
As calibration seems to be necessary from time to time I added a return value 
to the calibrate method that gives the current calibration offset. This way 
from a macro someone can do local or remote calibration from time to time and 
see the result. Don't think this should be done via REST so I did not add a 
REST mapping for now. The final vcnl is also attached.

Original comment by andreas....@googlemail.com on 26 Feb 2013 at 8:14

Attachments:

GoogleCodeExporter commented 9 years ago
Nice !
Thanks for feedback, and happy your VCNL is finally working.
I close the issue, and I'll update the VCNL driver later today.

Original comment by tro...@trouch.com on 26 Feb 2013 at 1:49