Wildcards in Config options

[iamdual]

Wildcards in Config options

[GoogleCodeExporter]

I would like a more explaining example with a specific device class for 
instance.

Original comment by [email protected] on 25 Feb 2013 at 1:41

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

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 [email protected] on 25 Feb 2013 at 1:58

[GoogleCodeExporter]

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 [email protected] on 25 Feb 2013 at 2:04

[GoogleCodeExporter]

or 

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

Original comment by [email protected] on 25 Feb 2013 at 2:09

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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 [email protected] on 25 Feb 2013 at 7:26

[GoogleCodeExporter]

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 [email protected] on 26 Feb 2013 at 8:14

Attachments:

• device-monitor-1.PNG
• device-monitor-2.PNG
• i2c-detect-sensors.PNG
• vcnl4000.py

[GoogleCodeExporter]

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 [email protected] on 26 Feb 2013 at 1:49

• Changed state: Fixed