I2C/SPI/1-Wire support : Device/Component wish list poll

[trouch]

With the upcoming release, you will be able to use some Serial/I2C/SPI/1-Wire devices directly from the REST API without writing macros.

To do this, WebIOPi need somes drivers that use a special Python function decorator.

Low level acces to I2C/SPI/... is provided by lightweights classes available in the WebIOPi core without dependencies.

Drivers simply use those classes, and the decorator to expose functions on the REST API.

Configuration is then provided with a new /etc/webiopi/config file.

I cannot write a driver for all components, mainly because I don't have them, and I cannot buy everything.

I could write drivers simply reading specs, but I will not be able to certify it work.

Everything will be documented to help the community write drivers, and I hope people will submit some.

But I would like to include most used components I can hand on.

I already wrote few ones that will be included in WebIOPi for devices I have.

I'm also waiting for few sample and purchase orders for several component I identified.

Drivers ready :

MCP3004 - SPI 10-bits 4-channels ADC

MCP3008 - SPI 10-bits 8-channels ADC

MCP3204 - SPI 12-bits 4-channels ADC

MCP3208 - SPI 12-bits 8-channels ADC

TMP075 - I2C temperature sensor

TMP102 - I2C temperature sensor

TMP275 - I2C temperature sensor

PCF8574 - I2C 8-channels I/O expander

Drivers planned / have devices :

BMP085 - I2C pressure and temperature sensor

MCP4922 - SPI 12-bits DAC

Drivers planned / free sample - waiting :

MCP23017 - I2C 16-channels I/O expander

DS1307 - I2C Real Time Clock

DS18B20 - 1-Wire temperature sensor

Drivers planned / purchased - waiting :

PCA9685 - I2C 16-channels PWM/Servo driver

Submit your devices

Feel free to submit any component you use and/or would like to use with WebIOPi.

Depending on demands, I may write the driver it if I can have one sample.

If possible, add a link to its datasheet.

How to help ?

If you absolutely need particular one, you can send/buy me a sample or make a donation, I will write the driver required.

If you know how the device work on it's low level interface, look on the source repository, start with PCF8574 Driver, write your own and submit it.

Feedbacks and comments are welcome, thanks for your help !

Eric.

[Andreas Riegg]

I have the following devices and will (try .... :-) ) to submit drivers for (in the sequence of complexity/effort and thus timeline to expect them):

 

- DS1822 - 1-Wire temperature sensor (protocol should be identical to DS10B20, maybe it can be used directly with DS18B20 driver, I will test this before coding when DS18B20 driver is available)

- MCP4725 - I2C 12-bits DAC (1 channel with additional persistent mode, high similarity to MCP4922 expected, will wait for MCP4922 driver to check difference)

- Olimex MOD-IO2 - I2C "composite" adapter PCB, combines digital IO, 2 relais and analog input (quite simple protocol, basic code with digital.py and analog.py already exists, seems to be limited straightforeward effort) 

- ADS1015 - I2C 12-bits 4-channels ADC (some raw similarities to MCP3204 exist, but other IC vendor will make command tweaking/bits shifting necessary)

- TSL2561 - I2C  2 channels light (infrared+visible; infrared) (visible can also be derived by subtracting, but device is somewhat complex, driver coding will take some time + effort)

- VCNL4000 - I2C proximity/light (same complexity as TSL2561, will take time, has lowest priority)

 

Andreas

[trouch]

I can have free microchip and maxim sample easily

Today I received few DS18B20 I ordered last sunday.

Shipped from Thailand to France in 4 days by DHL for free !

Maxim says they are the most generous, and they are right ;)

I also plan to make sample order on microchip for I2C DAC and ADC

I also like the olimex adapter I may purchase for me.

You can focus on ADS1015, TLS2561, VCNL4000 if you want.

Thanks for your help.

Eric.

--
You received this message because you are subscribed to the Google Groups "WebIOPi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webiopi+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andreas Riegg]

OK.

 

The TMP 75 and TMP275 I own are also free samples from TI.COM shipped for free in 2 days via FedEx from somewhere in Minesota/US to me :-) :-) :-)

Anyway they will be used for charitable purposes in this community which should be helpful for all.

 

Andreas

[trouch]

I've created a wiki page to summarize device support and plans :

http://code.google.com/p/webiopi/wiki/DEVICES

 

Andreas

--

[trouch]

TI I2C ADC samples received, but I hoped I could solder some wire directly on the chips. 

It seems I will need to try CMS soldering before being able to use them.

[Stuart Marsden]

I am looking at using a DS2408 1-Wire 8 channel switch. Once I have figured out where to get one cheap delivered to Finland then I will add a driver. It is kind of a GPIO expander but is open drain, not high low. I guess I will extend the GPIOExpander class. The DS2408 has a kernel module so should be simple enough to support.

[Andreas Riegg]

Manual soldering of SOIC 1.27' pitch chips is ok and I did that using adapter PCBs for the TMP75 and TMP275. However, doing the same for 0.65' pitch chips is much harder to do and thats the reason why I use typical complete adapter Breakouts from e.g. Adafruit for those. They cost a litte bit more, ok, but typically for home automation you don't need hundreds of them. Anyway good luck in soldering the ADC samples.

 

I just started some preliminary experimental work on a driver for TSL2561 and came across two questions:

 

The device is in power-down mode after a power cycle and needs a wakeup command sent to a control register. Is it ok to put this I2C writeBytes(..) at the end of the __init__(..) method of the device class or will this fail due to some initialisation and bus driver loads and should be done in the first call of any of the routed methods using a state variable like "if not initialized" ? Or maybe a callback at the end of all other initializations to all loaded devices like deviceInstance.initializeDriver() would make sense? Btw. there could be also a call at shutdown like finalizeDriver() to put the devices to powerDown again to save energy .... OK they regulary dont consume that much energy.

 

Various devices (e.g. sensors or ADCs) sometimes need some time for conversion in single shot mode or after wakeup (see above, TSL2561 needs 400ms after wakeup call to be ready and have the first value to read.). The HTTP and CoAP handlers run in own threads but the other parts of Webiopi-Server not. Are there (planned) any mechanisms to avoid blocking and/or concurring calls on busses and to cope with say waiting times for results? Sometimes devices have a control bit that can be queried for end of conversion, but that would imply a sleep() or bit-poll within a driver, but that sounds like a bad idea to do this as this will block. Or should we wake up all devices (if necessary) at driver start and use only the continuous sensing modes for the chips after that?

 

For testing my driver I will wait until the next Webiopi release is stable as it undergoes still major changes in the trunk from what I see. But thats ok as you are really putting excellent functionality inside those modules.

 

Regards Andreas

[trouch]

Actually, I should say yes, extend GPIOExpander and OneWire, like the PCF8574 does with I2C.

But GPIOExpander is really new, and I'm not sure to keep it in this state.

I added a GPIODriver class yesterday to extract all GPIO stuff from the RESTHandler, and I'm thinking to generalize something between GPIOExpander and GPIODriver without having any issue or confusion with under-laying GPIO native library.

Nothing is frozen right now, and I may break some current features/naming by making other changes.

I think all 1Wire devices will require additional module

If you look at OneWireTemp, I added TEMP as an extra module required, you can do the same with DS2408, there is a list on top of onewire.py to add modules :

EXTRAS = {

"TEMP": {"loaded": False, "module": "w1-therm"},     "2408": {"loaded": False, "module": "w1-ds2408"} }

Then 

class DS2408(OneWire, GPIOExpander):

def __init__(self, slave=None):

OneWire.__init__(self, slave, 0x29, "2408", "DS2408")

def __input__(self, chanel):

raise NotImplementedError

def __output__(self, chanel, value):

raise NotImplementedError

Replacing error raising with access to to device, through its w1_slave file I guess.

Hope this help,

Eric.

[trouch]

Yes adafruit's breakout board does not cost much, shipping is more expensive.

Having ADC and DAC support on  I2C and SPI should be a great thing for the next release.

Other "exotic" devices can wait everything is frozen and stabilized, but any submission is welcome.

I think there is no problem to read or write and the end of __init__. An error will raise before if something is wrong with modules loading.

Good point on locking devices if you have to wait. I will see what can I do to help this, or if you will have to use directly threading.Condition()

I'm glad you like changes I make. I spend hundreds hours last week as I was not working, and I'm quite happy of the result.

I cannot say it's stabled enough to be used, but I try to make as many test I can before each major commit.

Right now, apart from edge detection/push optimization, there is no more open issue, but I have new idea all days.

After extracted GPIO from RESTHandler, I started to move Serial configuration in DEVICES.

I also started few Javascript classes to use all new stuffs.

I wanted to release some minor changes before the magpi february number, because there is few issue fixed on the trunk.

But new features came faster as expected, and I need to make everything as most consistent as possible.

I will have to stop adding new features quickly to start a big testing process before release it.

Eric.

--

[Stuart Marsden]

Have just ordered these 1-Wire samples from Maxim:

DS2438Z+                      2                 Smart Battery Monitor

DS2482S-100+                  2                 Single-Channel 1-Wire Master

DS2482S-800+                  2                 Eight-Channel 1-Wire Master

DS2408S+                      2                 1-Wire 8-Channel Addressable Switch

DS2438AZ+                     2                 Smart Battery Monitor

I am a software guy and not much for electronics so hoping this will make putting the chips on the breadboard easy. The battery monitors are interesting as they basically give an A/D voltage and current monitor that can be used for anything as well as a temp sensor.

Will be a few weeks until I get the adapter from china but assuming it all fits and I can get it to play I will add drivers for webiopi.

[Andreas Riegg]

Hi Eric,

just tested TMP075 and TMP275 and can confirm testing ok with reading celsius.

Seems that default resolution is set to 9 bits which results in 0.5 degree steps resolution. We may add an additional method and rest mapping to change config register to enable the other modes on 10, 11 and 12 bits. Using 12 bit increases sampling time up to 220 msec ... but 4 values per sec should be still ok for temp sensors. Does this also apply to TMP102? If not I may try to add this this for TMP075 and TMP275.

Regards Andreas

[Andreas Riegg]

Just checked the specs form TMP102 looks like its config and default settings are different (12 bits) but some compatibility is maintained with TMP075 and TMP275. As resulution cannot be set for TMP102 this will have to be specific to TMP075 and TMP275.

Andreas

[trouch]

This is cool ! I will take a look on configuration register for TMPx75

You are welcome to submit something, but I'm making little changes on I2C, digital and analog devices

I've added/changed read/writeRegister in I2C for instance.

I hope to commit tonight, I have to make some more test.

Yesterday I had PCA9685 PWM driver working !

Eric.

On Sun, Feb 10, 2013 at 10:06 PM, Andreas Riegg <andrea...@googlemail.com> wrote:

Just checked the specs form TMP102 looks like its config and default settings are different (12 bits) but some compatibility is maintained with TMP075 and TMP275. As resulution cannot be set for TMP102 this will have to be specific to TMP075 and TMP275.

Andreas

--

[Andreas Riegg]

As a quick shot I have attached the modified sensor.py that I'm working on to add the resolution stuff to TMP275 (but should be identical to TMP075). I was not able to test it, maybe you can start with that.

 

It also contains a modified  __getCelsius__ as the original version does not work with negative temperatures (twos complement that the TMP's use). Its only tested in Python shell to work correct but not with real devices so far. Hope that helps.

 

Andreas 

[trouch]

Thanks, I will take a deeper look on that when I'll finish other things.

I already have a comment : I don't like the ability to change the resolution through the REST API.

It should be set in the constructor, so we can change it with the config file.

Then getting the resolution with the API as a meaning if we also expose raw data.

Thanks for the sign correction ! I guess, it the same thing for all TMPXXX.

I may correct TMP102 too.

Eric.

 

Andreas 

--

[trouch]

I've added resolution change support in TMP75 and 275, with default to 12bits.

It's done through the constructor:

t = TMP075(0x48, 10) # TMP075 at address 0x48, with 10bits resolution

in the config file :

tmp = TMP075 0x48 10

there is an error in your code :
new_byte_res = bits_res & self.MASK_RESOLUTION always gives 0, for example with 12 bits:

   MASK_RESOLUTION = 0x60

& VAL_RES_12_BIT = 0x03

----------------------------------------------

0x00

So you always set it to 9-bits

I also corrected integer sign.

I cannot test outside temp, but I checked with datasheet examples values.

Thanks

Eric.

[Andreas Riegg]

Your're right, i copy-pasted the resulution code from my alpha TSL2561 driver and there the bits sit at position 0 and 1, forgot the << 5.

 

The I2C write/read register(s) methods help a lot to keep code lean especially with a device with so much registers as the PCA9685, will adapt this to TSL2561. This guy is a little bit beasty in register addressing and wants to have bit 7 also set to 1 additional to the register address in bits 0 to 3, but this can be easily achieved by just adding 0x80 to each register address which is no effort.

 

Also the idea of giving hints in REST mapping to result units like c, f, pa or hpa is very bright. So this will end up for TSL2561 with an e.g. /luminosity/lx mapping.

 

Maybe I can find the electronic circuit testing ice spray I once had in my fundus and check the negative temps with that on my TMP075 and TMP275.

 

FYI, I will be offsite and offline for the next few days.

 

Andreas

[Andreas Riegg]

Forgot one additional point.

 

Some REST mappings use abbreviations "temp", some others not "pressure", maybe its an idea to have this unitfied like all are abbreviated or all are full spelled. Dont't know if too long path names may be a potential problem, however they could be overcome with routes and they also are pure virtual and don't access any physical file system paths. Maybe some influence on frame size for CoAP requests.

 

Andreas

[trouch]

Yes, I'm not sure of what URI mapping use for temperature. I tried to get something shorter.

I agree this is currently nonconsistent with pressure.

I think I will simply go back to "temperature".

 

Andreas

--

[Andreas Riegg]

Hi Eric

back online now.

Was able to test my TMP75 and TMP275 with r911. Found 2 bugs:
- in sensor.py is still a reference to TMP075 in __init__ of class TMP275, corrected it to TMP75
- when providing a resolution parameter in config like e.g "temp1 = TMP275 0x49 10" this throws an incorrect type exception. Adding "resolution = int(resolution)" before "if not resolution in range(9,13):" solved the problem. Code expects an int parameter but gets a string from config (obviously ...)

With the changes above all worked correct including changing the resolution within config (tested all variants form 9 ...12).

Was also able to test negative temperatures (at least until -0.5 C) and value was ok when going below 0 celsius, so twos complement TMPXXX works correct.

Regards Andreas

[trouch]

Thanks for your feedback Andreas, it's really appreciated. I will quickly fix TMP(0)75 this evening.

About the int handling from config, I think I need something more generic, may be on top of driver instantiation.

I had this issue with other devices / args, and it may be present somewhere else...

Eric.

[trouch]

everything should be fixed with r912

[Andreas Riegg]

just tested, is ok with r912.

also tested BMP085 with the one I have, also ok. One (very small) finding with that: According to data sheet BMP085 delivers temp with 0.1 resolution, default answer of class Temperature is .2f and I also get values like 25.34 C, seems Python div has higher precision than algorithms from BMP085 spec have in mind. Or they assume integer/long divisions, seems to be not detailed further in data sheet.

andreas

[trouch]

thanks Andreas, I changed their support status on the wiki.

this evening I've reorganized files to help device adding and clarify packages.

I also added a Luminosity sensor class, and TSL2561 skeleton as I understood you are working on it.

andreas

--

[Andreas Riegg]

Ok I have seen that. Just give me a short note when you have finished/stabilized reorganizing the devices packages so that it makes sense to finish TSL2561 and plug it into the final device classes/structure the right way and test the driver before submitting it.

andreas

[trouch]

I checked everything was working before committing changes, so I think it's ok.

I don't have more sensor to play with, so I don't think to change the sensor package anymore except for bugs fix.

same for I2C. 

Luminosity and TLS classes are suggestions, you can change it if you want.

feel free to work on TSL when you want.

on my side I need to continue on Javascript code. 

On Sat, Feb 16, 2013 at 11:48 PM, Andreas Riegg <andrea...@googlemail.com> wrote:

Ok I have seen that. Just give me a short note when you have finished/stabilized reorganizing the devices packages so that it makes sense to finish TSL2561 and plug it into the final device classes/structure the right way and test the driver before submitting it.

andreas

--

[Andreas Riegg]

Eric,

 

here is the beta of my TSL2561 driver. I tested it yesterday evening with my device and it was ok. I also tested the different config/constructor options and they were also ok. Changing light gave consistent changing lux values however as it was at home in the evening I only got values between 0.5 and ~ 1000 lux using different lamps. Was not able to test in direct sunlight :-) will do this at the weekend.

 

I also made a wiki file (currently in original mediawiki syntax, looks like Google Wiki syntax is a little bit different, is it documented somewhere?) that may be a proposal for Wiki pages for every device/device family. Giving this kind of information will help to keep forum help calls on driver questions low ....... saving time for development. A link could lead from the devices table to the device pages (if available).

 

The TSL2561 chips come in 2 flavours with different packaging -and- the lux calculation formula is different for both. The real chip version cannot be drived at runtime so I created two subclasses. For that I also changed __init__ to add both imports. I will also add a driver for this device (http://www.watterott.com/index.php?page=product&info=2860, chip is from TLS4531x family). Its cheaper than the TSL2561 breakout from Adafruit that I already have and I will buy this additional one sometime in the next weeks. Its from the same chip manufacturer and driver will be 90% the same. For that reason I made the superclass TSL_LIGHT_X and will put the TSL4531x classes below as the TSL2561 classes are now. Maybe it makes sense to rename tsl2651.py to tsl_light_x.py to prepare for that.

 

After testing I made some small cosmetic changes to the driver, hope I did not break anything ...

 

Andreas

 

PS: I post the files separately as adding to this post does not work with my IE8 .... dunno why

[Andreas Riegg]

Here they are via Firefox ....

[Andreas Riegg]

Can post only one by one ....

[Andreas Riegg]

Last one ...

[Andreas Riegg]

Problem was probably the file with mediawiki-syntax and neither IE8 nor upluading multiple files. Google forum software tries something with it that leads to a HTTP 340 error. Posted it as ZIP instead.

Sometimes IT is OMG!

Andreas

[trouch]

you could send me a mail ;)

I'll check all of that later, many thanks.

About documentation, there is nothing yet for new features

[trouch]

Checked your code, and only have a single question :

Do you will override __set/getGain/Time__ with TLS4531x ?

If not, we can put the code directly in upper methods without __ prefix and suffix.

Appart from that, I have nothing to say, good job.

I will add it on the trunk so you will be able to test it a last time, then I will update the wiki DEVICES page.

Thanks for your work,

Eric.

[Andreas Riegg]

TSL4531 has no possibility to set gain, this will remain unique to TSL2561.

 

TSL4531 has the possibility to set time, but with different values. I think it is possible to put set/getTime on TSL_LIGHT_X level and have then two different __set/getTime__ implementations on current TSL2561X and future TSL4531X levels.

 

The missing gain was also the reason why I put the time config constructor parameter before the gain one.

 

Q1: Do you think it makes sense to return the written value after being set to have security that is is really set? Method would then be:

def setTime(self, time):

    self.time = time

    self.__setTime__()

    return self.__getTime__()

On the other hand, this will mean additional I2C traffic, I'm not sure if thats really ok thinking at performance ...

 

Q2: I think the next driver I will do for a device that I have will be the VCNL4000 one. Its a combined one as the BMP085, having the "Luminosity" part which is already there (and similar to TSL...) and a new part dealing with distance mesuring. To prepare this it would make sense to add the attached fragment to the end of __init()__ within the sensor package.

 

Driver name could be vcnl4000.py and the class VCNL4000 inheriting from I2C, Luminosity and Distance.

 

Andreas

 

 

 

[trouch]

Ok, let see how you will integrate TSL4531 later to simplify all TSL light sensor package if required.

No problem for Q2, I will add the Distance class. I let you write the whole vcnl file ;)

For Q1, it depend on if you want to expose it to REST API. If no, we don't care.

If yes, then you should return self.getTime() for consistency with other APIs, and to ensure the value has been set as expected.

Saying about performance, unless you use WebIOPi with a lot a clients, I think reading an I2C value is insignificant compared to network latency.

But we may do some timing test on this.

Eric.

 

Andreas

 

 

 

[trouch]

TSL driver and Distance interface added in r931.

Let me know if it works.

Thanks again Andreas.

[Andreas Riegg]

Eric

TSL driver and distance interface work as far as I could test them (see below).

I have completed the VCNL4000 driver, at least to some extent. The luminosity reading is tested and ok so this part is final. Looks like the sensitivity especially in low light situations of this chip is better than the readings of TSL2561. The downside of VCNL4000 is that I was not able to really test the proximity readings with the breakout I have. I implemented the proximity part of the driver according the application note from VISHAY and it works without problems so far. The parameters of the VISHAY algorithm for the number of calibration cycles, the proximity measuring cycles and the threshold can be set via config options. But after a long series of tests and hardware fiddlings I'm pretty sure that the proximity detection part of the chip I have must be defect. Its either the IR LED not working at all or the IR detector having a problem.

The symptoms are that I get some proximity readings in the area of around 2700 counts, but they are almost the same value in every case. They show some small variations, but the massive increase that should be noted when putting something really near to the IR sensor does not happen. I tried the device with different power sources via 5v or 3.3v but no change happens and varied many of the register settings but no change either. The most odd thing is that when I change the IR frequency to the highest value of 3125 kHz I only get 0 raw value readings. So with high probability I think the chip is defect but I have not the electronic equipment to really prove this. As I don't want to do a RMA procedure for a breakout of 9 € value I will leave it the way it is right now.

Inside the driver are some debug statements that allow to see the raw readings from the chip. Maybe some other person having a non-defect chip may use this to do a better calibration of the distance lookup in __calculateMillimeter__.

Next week I hope to get the TSL4531 breakout I ordered and finalize the TSL driver so that it covers the TSL2561x and TSL4531x family complete.

I will send you the driver for VCNL4000 via direct mail to avoid the upload hassle from the last time ...

The next thing I will code will be the driver for the MOD-IO2. As this is a combined expansion board and I have seen that you intend to write drivers for other combined boards I will first wait how you will start this as this kind of boards don't fit into the current drivers package structure very well. Maybe an extra subpackage like "expansion_boards" or so with additional framework classes is necessary.

I also tested the new device monitor page which very cool for testing. The only thing I noticed is that it does not show the distance readings.

Andreas

[trouch]

I received your mail Andreas with the code, thanks !

I totally trust you about the VCNL driver, I can't test it but I hope someone else will.

I'd like to buy one but I have other priorities... May be later.

I will add your code tonight I think.

On my side, I'm waiting for few purchase and sample orders (more MCP23XXX, I2C DAC and ADC)

About the PiFace shield, it should simply rely on MCP23S17 chip I sampled.

I think to release 0.6 after I received and implemented my last orders.

Arduino board (and certainly MOD-IO2) will wait for 0.6.1 or next version.

There is still a lot of thing to do, but I'd like to get more feedback before planning something new.

And I think it's time to release the two past months work.

Have you tried /app/devices-monitor ?

I think I'm done with Javascript upgrade for devices support in 0.6.0

Thanks again for the code !

Eric.

Andreas

--

[Andreas Riegg]

Yes I also tested the devices-monitor after I discovered it looking at trunk updates soem days ago. It's very helpful for testing and I was already thinking of creating something like that to avoid the permanent F5 clicks when testing my drivers. I this case you read my mind :-).

 

The things that could be improved before release are:

 

The BMP085 showed up automatically with its two readings for temp and pressure. The VCNL did only show the luminosity value but not the distance one, maybe some small piece is missing in the distance part of jscript or the json dump things, seems to me that nothing is missing on python driver level. But it may also be the case that I did not have the latest release. When finishing my TSL* work (the TSL4531 breakout will arrive mid this week) I will test again with the latest revision and see if it still misses.

 

To index.html I would add a H1 section giving a headline that this is the device monitor. Its already mentioned in the title tag but having it also inside the webpage would look a little better.

 

And, I would shorten the update time for lux. Temp does not change very quick, but lux may change very quick when waiving with a hand just over the sensor.

 

Putting Expansion boards to 0.6.1 or later is ok, I think its a good idea to do a release when current driver work is finished in the next days so that folks not looking at trunk every day see that webiopi is still "alive".

 

When testing my drivers and doing much work with config settings I got two additional ideas concerning this. One of them may be only 1 or 2 lines of python code and may find its way into the next release. The other is more effort and will be post 0.6.0 stuff. In order to have this input not buried down somewhere in this already very long thread I will put them as new issues in the issues list sometime later today.

 

Andreas

 

 

[trouch]

For the VCNL, a piece is missing : 

def __family__(self):

return [Luminosity.__family__(self), Distance.__family__(self)] Then the webapp will automatically display both information, just like the BMP085.

 

Andreas

 

 

--

[Andreas Riegg]

ok, so __family__ has to be in line with the multiple inheritance used in _init__ of the device class. I will add that.

 

Andreas

[Andreas Riegg]

FYI, received my TSL4531 breakout today and will be able to finish and test its driver inside tslxxxx within the next days so that it can make it into the next release (assuming this breakout functions better than the vcnl4000 one ...)

 

Andreas

[trouch]

Just a question about the TSL2561, which package is commonly used on breakout ? T or CS one ?

Is there any sense to make a TSL2561 driver which could simply extend TSL2561T or TSL2561CS to simplify using it for people who don't know their package ?

I also received my ADS1015 I2C ADC and MCP4725 I2C DAC yesterday, I think to work on it before the week end.

I'm still waiting for MCP23S08/17, but implementation should be fast as it's quite same as MCP23008/17.

On Wed, Feb 27, 2013 at 12:11 PM, Andreas Riegg <andrea...@googlemail.com> wrote:

FYI, received my TSL4531 breakout today and will be able to finish and test its driver inside tslxxxx within the next days so that it can make it into the next release (assuming this breakout functions better than the vcnl4000 one ...)

 

Andreas

--

[Andreas Riegg]

The breakout I have is the one from Adafruit and it has the T package (according to the pictures and the sample c++ code from them).

 

The problem is that it cannot be determined at runtime (e.g. by reading the ID register) which one is used. The only change between the devices is that the lux calculation formula is slightly different. So, when using the wrong package in config, nothing will crash, just the returned lux value will be not correct ... and when looking at the differences, the two values will not be very different any way, so ....

 

When you look at the device-monitor screenshots from yesterday you will see that the lux values returned form TSL2561T (with gain set to 16 as it was low light situation) and VCNL differ by 100 % However, they were just 5 cm beneath each other on the same breadboard and light intensity cannot not be so different for sensors having the same illumination!! So I would not really trust in the absolute values very much. You get indications if its dark, normal or really bright, but correct absolute values need professional luxmeters.

 

But yes its a good idea, I can implement a "default" TSL2561 device that inherits from the T Package as I think the CS type package is much smaller and not available as breakout so far. That will be then automatically ok for the most people as I assume they will use available breakouts from the market.

[trouch]

It's enough for me. I will had a note about that in the device support page of the wiki.

[Andreas Riegg]

Had some time today as I was at home supervising some craftsmen doing some repair work.

The TSL4531x Driver is now also ready as I had no hassle with the breakout. Its tested with r992 and integrated into tslxxxx. I tought of making only one class for all four TSL4531 variants as the type in this case can be determined by the ID register, but they have different I2C slave adresses and only one which can't be changed (same as bmp085). Only possibility would be to have a generic TSL4531 class but in this case the slave address MUST be given in the config otherwise the ID register cannot be read to determine the used device. Can also be a source of errors or misunderstandings so I kept four classes. As the devices are 100% the same excluding the slave address it does cause no error if someone uses the wrong class in config as the only thing that really matters is to have the right slave address.

Please find also attached some screenshots again. I added a top shot when running devices-monitor r992 with all devices attached. CPU is around 10% and memory consumption seems to be very moderate.

Andreas

[trouch]

thanks, I'll take a look on that tomorrow.

[trouch]

Looked on your TSL4531 driver, I have a question/suggestion :

Cannot we rename TSL4531X to TSL4531, and change its init to

    def __init__(self, slave=0x39, time=400, name="TSL4531") ?

I think that someone using 0x29 with 45315 or 45317 is aware of that and will use the specific driver or give slave adress with the generic driver.

For most people, they may just buy the breakout as a 4531 without carrying about the package. I just hope 0x39 is commonly used.

What is your package ? Where do you find the breakout ? Googling TSL4531 breakout does not return so much result.

Eric.

[Andreas Riegg]

I have this one: http://www.watterott.com/index.php?page=product&info=2860&xab2df=034eb47cadfa4991f4a9ab61fa78fe23.

 

Well, its a german company so worldwide supply will be not common, but within Europe it should be ok. But the breakout has advantages:

- Its cheaper than the TSL2561 breakout from Adafruit

- Looking at TAOS website this chip is a newer generation than the 2561

 

On the breakout above I have is a TSL45315 and looking at TAOS specs I assume that the TSL45317 is the "standard" one. They both have address 0x29 So I think we can do the rename what you propose but use 0x29 instead of 0x39 as default slave address.

 

FYI: Within the code of TSL2561 is missing some small piece to correct use the integration time and gain scaling. I observed that when coding the __getLux__ of 4531x

(see line "return self.multiplier * (data_bytes[1] << 8 | data_bytes[0])". The data sheet of 4531 is much better than the one for 2561 as it explicit names this. I made the correction for 2561 already but want to test it to be correct with the device before releasing it. Think I have the time for that this weekend.

 

Andreas

[trouch]

Thanks for your help, I just committed your TSL4531 driver.

 

Andreas

--

[Andreas Riegg]

Hi Eric,

had the time to finish the TSL driver today. It has now two "default" classes TSL2561 and TSL4531 that work out of the box with default values. The scaling is now correct. I had also the chance to test the driver and breakouts in direct sunlight. They work correct, however they start to clip in strong sunlight as the values get to high.

For the VCNL there is no chance to mitigate that within the driver as the luminance part has no parameters to tweak.

For the TSL chips this can be improved by implementing an automatic mode that changes integration time and/or gain (2561) on the fly. The cpp v2 driver of Adafruit has something like this. But this will be features for the next release of the driver. If someone needs that before it can be implemented in a macro as all methods to change gain and time dynamically are already available.

I also made some final default parameter changes to the VCNL driver, so they are both included. That's it so far, I will now wait for the 0.6.0 release being out before implementing more drivers.

Andreas

[trouch]

Nice, many thanks for your help Andreas, it's greatly appreciated.

I just updated the repository with the changes.

Andreas

[Stuart Marsden]

I finally got my samples and chip holder so have begun making new drivers for webiopi. The first is for the DS2408. The attached patch seems to work for me. The input works as expected. The output is open drain type so 0 means that it attached to ground usually completing the circuit. 1 means high resistance so probably means the circuit is off. 

The kernel driver for ds2408 is a bit simple just giving binary access for reading and writing. It seems to deal with bad CRCs by giving an IOError so I have caught them. This means that reading can return None sometimes if we caught an IOError. This can cause problems elsewhere like this:

 File "/usr/local/lib/python3.2/dist-packages/WebIOPi-0.5.4-py3.2-linux-armv6l.egg/webiopi/devices/digital/__init__.py", line 118, in readAll

    values[i] = {f: func, v: int(self.input(i))}

TypeError: int() argument must be a string or a number, not 'NoneType'

Not sure what can be done about this. Could return 0 instead of None but this would be a false reading. The driver could try reading several times until it gets success. Or None could be recognised and perhaps return 'Unknown' or some such value.

Please give any comments on the patch and I will do my best to fix them.

[Andreas Riegg]

Stuart,

 

readAll is used to produce the json state map of all digital inputs (in your case 8). It reads all inputs sequentially, maybe the 2408 driver gets timing problems as 1-wire reading may take more time as python someway gives it. not sure if the 1-wire bus reading with 2408 kernel driver blocks or not and checks the ready bits if available correct.

 

you could answer -1 as I do (currently) in my drivers for invalid values, this will at least avoid the exception. but its then up to the REST API or python API user to deal with those -1 results correct. and keep in mind that code used to toggle digital outputs that uses "not value" will interpret -1 as 1 as its non-zero and that code checking GPIO.HIGH/LOW may also fail or produce false results. but -1 cant be the final sulution. in my case -1 is ok for lux or proximity values which never have negative values, but for temperature sensors negative values are valid, so that wont work consistent in this case either.

 

In longer term we probably need some error or problem classes in utils.py that are global available to webiopi. these classes can be checked directly in python code (e.g. within macros) and should lead to apropriate HTTP/CoAP error codes for REST responses. But implementing this maybe is a lot of work (and testing ....) for Eric and more a candidate feature for next releases.

 

Andreas

[Stuart Marsden]

Andreas,

I think it is the driver's way of dealing with a bad CRC. On my system I can see that the REST call for readAll usually takes about 180ms but occasionally jumps up to about 1000ms. This is from my laptop on a wireless connection to the Pi so variance is most likely that.

I will adjust my driver to give -1 on error to be consistent with you but it is not ideal as you said. At the moment if I have the Device monitor running and thus polling every second then I get a TypeError after maybe 2 minutes and sometimes as fast as a few seconds. This seems in line with the number of CRC errors I have seen on my temp sensors. The Device Monitor stops polling when it does not get a response from the server and so my GPIOs are no longer updated. I just need to refresh the page as the server does not need to restart. This would not be acceptable for finished product so hopefully returning -1 will be better and stop exceptions at the cost of a weird value.

It would also be more efficient if ReadAll used the readInteger method when available. I suppose the driver could store the integer internally and check how old it was. If it was less than a threshold (maybe 50ms) then it would use that value and save polling the onewire bus. Would be fairly simple to implement and the additional latency would be small compared to network delays anyway. The 2408 has a latch to catch transitory signals so if I could figure out how the driver exposes it then it could help make up for longer latency.

Stuart

[Stuart Marsden]

Slightly modified patch based on feedback from Andreas.

It now returns -1 instead of None when it gets an IOError. This stops it causing exceptions in readAll which would stop the client polling for updates. This now works well but does occasionally give the spurious -1. I believe the cause of this is due to a bad CRC causing a file error in the 2408 driver.

As Andreas has said there should be a better way of dealing with these error conditions.

[Andreas Riegg]

Just as a side question, do you have any information of a DS2406 kernel driver. In the midterm I would like to use this chip to control 12/9V relais in a chainable 4-wire connection (GND, 5V, 9/12V, 1-WIRE-DATA) with the possibility to have longer lines (.... connected with EMV protection to a DS2482-x, not GPIO4). The DS2406 is logically a 1/2 channel version of the DS2408 and the TO92 package is very suitable for hobbyist hardware driving the relais with an additional FET. Or is this driver already contained in the Raspbian distribution?

 

Andreas

[trouch]

Thanks for the patch !

Globally, 1-Wire devices seem to be very slow and more subject to error.

Then, error handling has to be improved in devices REST calls.

As Andreas suggested, few Error classes will help by raising them in the drivers then catching in the REST Handler.

In this case a "DeviceError" that will be propagated into a 503 "Service Unavailable" HTTP code.

About the readAll method, it also has to be improved in all digital drivers because it loops on both IO byte reading and bit extract.

I could make a single byte read, then loop onto it to extracts bits.

It should help with 1-Wire I/O Expanders by avoiding too many CRC error, and it will improve other drivers speed.

Right now, I would like to freeze WebIOPi until next release, by only fixing "nominal cases" bug.

I don't want to add new stuff, so I'm not sure to add your DS2408 driver yet.

We'll see...

--

[Stuart Marsden]

The errors that I am seeing are fairly sporadic but I have not tried a long wire yet so could get worse. One way to deal may be for the driver to try a number of times until it gets a good value. This could be configurable as it would increase latency but in some cases would be better than no value. Perhaps even a different REST call which could include the number of tries. Obviously that would be for a later release.

Changes to readAll seem sensible and should not be too hard.

The driver is fairly stable from my point of view and should only be used if someone adds that device in their config. May be worth including but marking in your device config as 'initial' or some other caveat. May at least then get some bug reports if anyone does enable it.

I will be working on a few other onewire drivers and also look at how webiopi can use a DS2482 for onewire instead of bit banging.

[trouch]

Well, just added in r1018, thanks.

About DS2482, we need to know if there is kernel module to provide another master in /sys/bus/w1

If yes, then we can simply reply on existing code as w1_modules should detect devices.

Eric.

[Andreas Riegg]

Eric,

 

I'm going to use my BMP085 for personal weather info and logging. Working on that I came across the matter of sea level normalization of pressure. As this may be also the case for other potential users I added the needed functionalities to the bmp-driver and __init__ of sensors.

 

In detail:

• I needed absolute temp in Kelvin, so thats a very simple addon in __init__
• There is a simple formula to do sea level compensation in the data sheet of the bmp without temperature compensation, it's implemented
• On Wikipedia is a still simple formula that does the same but including temperature compensation, it's also implemented
• As both formulas are in no way specific for the bmp I added them to __init__ also
• To do the sea level compensation the height of the sensor is needed, so thats added as config parameter to the bmp driver
• Temperature compensation has to be done with outside temperature (especially in winter for obvious reasons). If the BMP chip is run outside, its own temp value can be used for that. If its run inside (most likely the case) the outside temp has to be mesured with an outside sensor and I implemented some methods including a POST-REST mapping that allows to provide a outside temp from somewhere and get the correct compensated pressure direct from the bmp driver. In order to select this, I added another config parameter that can select to use the temp from bmp or not. if not, it uses the formula without temp compensation.

So, you find the modules attached. I tested them last night to be ok, but they also may be post 0.6.0 features, you can decide this free.

 

When testing this I came across another interesting point. When thinking about the MODIO2 driver I saw the problem, that it has digital as well as analog (ADC) functionalities. First I thought of just using multiple inheritance to get all the stuff, but then I realized that some polymorph functions will collide (e.g. readInteger is definitely different). As I think polymorphism is an important mean to keep code readable I now have the idea to define different classes (under a common superclass handling I2C stuff)  for each functional part of MODIO2 like MODIO2_ADC, MODIO2_GPIO, ... and inherit the individual functionalities and REST mappings like the pure devices. In config those individual classes can be instantiated using separate names and the usage would be very straightforward like single devices, e.g. modgpio = MODIO2_GPIO would lead to standard digital mappings and modadc = MODIO2_ADC to the ADC mappings. The only potential problematic thing may be that all those devices would point to the same physical I2C slave at the same time. When testing the new BMP functionality I just made the attempt to have two different bmp-instances in config with different names. one of them was configured to use temp compensation, the other one without. Everything worked correct as expected, so I just have the question if you see any problems in using this kind of pattern for mixed devices. If not this would be also a very elegant way to instantiate just the needed features of a mixed device (e.g. only the relais of the MODIO2) and keep the amount of REST mappings free from unneeded things.

 

Andreas

[trouch]

I will check BMP085 code later, thanks for feedback on these points.

For all future board support, I think it's not a good idea to try to inherits from existings devices drivers / abstraction layer.

It should be better to encapsulate them if you need some, then write all the REST mapping in the board driver.

For instance, the PiFace board use a 16-bits I/O expander for which 8 must be set as input, and 8 others as output.

And it has sense : a board is composed of components. So a board driver should be composed with component drivers if it exist.

With the MOD-IO2, you could have something in the REST mapping to select which function you are using :

/devices/io2/analog/...

/devices/io2/digital/...

I already wrote a PiFace driver but I can't test it yet...

Eric.

--

[Andreas Riegg]

Ok if I understand you right, this means that you have one driver class and one config device instance for piface, you instantiate some MCP23S17 object inside the piface driver, provide the complete REST mapping and special i/o channel settings for piface inside its driver and delegate the input/output mappings and calls to the MCP23S17 object methods.

 

Well, I think this is the best way to do when we have a board that technically is just something like a "customized" chip. It would be not ok to make a subclass of e.g. MCP23S17 inthis case. And we may see boards where more than one base chip is used, I have seen already some of them in the web.

 

In the case of the MOD-IO2 its a little bit different. It has a built-in MCP microcontroller that is controlled by its own I2C commands. But it has no I2C command structure that could be inherited by any of the basic chips we already have. However, for e.g. the analog part, only __readInteger__ has to be implemented to use the special I2C commands that read the analog ports, all the rest like setting channels and resolution including the base REST mappings can be just the same as for the other ADC chips which would be ok in the sense of minimizing learning of the REST API's of webiopi.

 

But your hint concerning the clear mapping separation is valid, so I will try to make one class that provides its own set of single device REST mappings, create GPIOPort and ADC objects and delegate some calls to them to be able to at least reuse some of their abstract methods.

 

Andreas

[trouch]

Hum, yes you are right.

I will have the same issue using an Arduino for digital IO, analog, and PWM...

Need to think a little bit more on this...

 

Andreas

--

[trouch]

Did not check yet, but may renaming *read/writeInteger* in *read/writeAnalogInteger* in ADC/DAC will help avoiding conflict when writing drivers that inherit from multiple abstractions.

REST mapping need to be changed too.

If I do this change, it will be for 0.6 release to avoid later change in the REST API and device abstraction layer.

[trouch]

Not worked so much on WebIOPi last days, took some day without coding at home...

But I took time to prepare a refactor of function names and REST mapping in device abstractions

See file attached, I'll try to make changes on next week end.

[Andreas Riegg]

Looks very good, especially the separate naming of the functions that simplifies multiple inheritance inside drivers.

Looking at the REST mappings there may be a little bit to improve. You use just one character for the type separation (a, p) or none (GPIO port). Maybe its better understandable to use a bit more like "ana" or even "analog" for analog, "pwm" for PWM and again "gpio" for GPIOPorts. Using just one character may lead to the problem that one day a second mapping may be needed starting also with "a" and then this may be a bit ugly.

So the results would be e.g.

- .../analog/count, analog/resolution
- .../pwm/0/integer
- .../gpio/*/integer

and for the sensors something like
- .../sensor/temperature/c

So the overall schema would be /device/<conf_name>/<type_or_abstract_class>/<numbering_if_applicable>/<value_or_unit_name> and * where applicable in between or at the end

This would also allow to map a "fat" board like an Arduino that may provide analog, digital, pwm and maybe even sensor or serial functionalities in a very consistent way.

As I mentioned in some other post, the length of names may have impacts. So I also thought about the mappings.

My conclusion was: The above mappings are the "technical" mappings. In order to be clear and mostly self-explaining it could be better to have a bit more characters but provide a good understandable path.

The routes already implemented are the "comfort" or "performance" mappings. They could be much shorter to hide the (longer) technical paths or reduce the characters sent in CoAP messages. Or they could be used to structure them more in a way to reflect the logical structure of a home as you do in the routes examples.

BTW I was also somewhat productive and could not resist to create another google code page for me allowing me to also provide some information without interfering with but prominent referencing your project. Currently it has only some documentation on wiki pages:

http://code.google.com/p/pi4home/

I don't have so much time and probably also skill as you for coding, but when looking at some of the help searching posts in the Google group I think I can help a lot by providing more documentation or documented experience over time.
I just see it as an addition to what you provide. If things like the driver documentation are ok for you, you just can copy them into your wiki and we use my side as something like a working copy.

Andreas

[trouch]

thanks for feedback.

originally, I wrote analog/pwm, then an/pwm and finally a/p to reduce the URI

using "analog" does not give so long URI, I will use it to make more human readable URI.

the except is GPIO, which I'll leave without prefix, for backward compatibility with RPi native GPIO mapping.

I also separated channel count and resolution to allow different settings with multi inheritance.

and yes, I also have to change others class like sensors.

Andreas

[Andreas Riegg]

Its absolutely clear that the original GPIO native mapping has to be kept . With gpio I meant the devices pcf8574 and mcp23... which did Not exist before 0.6 and may use a device/pcf8574/gpio/3/input like mapping which does Not break any thing that existed before.

Andreas

[trouch]

Anyone has tried last SVN changes ?

I'd like to release webiopi 0.6 this week end or monday

On Fri, Mar 15, 2013 at 8:34 AM, Andreas Riegg <andrea...@googlemail.com> wrote:

Its absolutely clear that the original GPIO native mapping has to be kept . With gpio I meant the devices pcf8574 and mcp23... which did Not exist before 0.6 and may use a device/pcf8574/gpio/3/input like mapping which does Not break any thing that existed before.

Andreas

[Andreas Riegg]

Eric,

 

the only things pending from my side that may be worth while for 0.6 are the Kelvin Temp additions for the __init__ of temperature sensors and the sea level compensation functions for pressure sensors, the added REST mappings for those and the bmp085 usage of those helpers plus the additional config options for bmp085 that I posted at March 8 above.

 

The __init__ changes from my patch have to be changed slightly to be conform with the patches from r1024 where you modified the temp helpers a bit and the new REST mappings just miss the sensor/ path modification.

The updated device abstaction functions do not interfere with this.

 

As I assume you also have a bmp085 device available you may be able to cross-check the additions before finally releasing them.

 

As the enhanced usage of the pressure sea level compensation with or without temp compensation is not trivial I may provide a enhanced bmp085 driver documentation as I did for the TSL devices already like this. You may link to this documentation or just copy the wiki-source to your wiki as it is already in the correct google wiki format.

 

As mentioned already the MODIO2 will be a post 0.6 work. From the Olimex forum I know that this device implements its own I2C protocol using a MCP controller firmware from Olimex that may cause problems on hardware level with the BCM I2C implementation. That smells like a more intensive test session needed which will take some time.

 

Andreas

[trouch]

I totally forgot that things ! I will check your patch for temp and sea level compensation.

I borrowed the BMP085 I have at work for the week end to try this.

I also still need to update the wiki.

 

Andreas

--

[trouch]

Andreas, I've looked at your code and added getPascalAtSea and getHectoPascalAtSea functions as well as Kelvin helpers.

Nominal pressure of BMP085 is already compensated with the temperature, so I'm no sure other functions are required.

If yes, I'll simply link another Temperature sensor as a class field to retrieve the outside temperature.

On my side, I found this pages :

http://keisan.casio.com/has10/SpecExec.cgi?id=system/2006/1224575267

and http://en.wikipedia.org/wiki/Atmospheric_pressure

Is it the wikipedia article you mean in your code ?

[Andreas Riegg]

Eric,

 

thanks for the additions. Looks like we're into applied pyhsics now .... but as we're engineers ...

 

The wikipedia article I'm referring to is this one:

 

http://de.wikipedia.org/wiki/Barometrische_H%C3%B6henformel

 

Unfornunately this is in the german language wikipedia and I did not find the exact counterpart in the international wikipedia so far.

Maybe you can unsdertand the article a bit using online translators to english or french.

 

In the article above at ca. 4/5 towards the end you find a part called

 

Anwendungen [Bearbeiten]

Reduktion auf Meereshöhe [Bearbeiten]

 

There is the formula (p(0) = p(h) (...) ) I refer to. If you put 15 degrees celsius (288.15 K)  as a constant for T(h)  into that formula and make some mathematical conversions you get exact the formula from the bmp085 data sheet. The bmp085 is compensated for its internal effects of temperature on its sensors, bot not for the temperature compensation for sea level calculation.

The formula from the data sheet does this kind of compensation assuming a standard temperature of 15 C which is ok for "normal" weather. However, if its very cold or very hot outside you get errors in the amount of some hpa (2-4) (see table below formlua in article). If you put the outside temp into the formula, then the value gets more accurate.

 

Now we have two possibilities:

1. If the bmp sensor is in some outside location, its own temperature measurement can be used directly for the better formula

2. If it is inside (more likely to prevent it from heat, humidity or ice), some outside temp from another sensor that is outside must be used.

 

Thats the reasons why I put some more methods into the driver.

May it makes sense to put the more sophisticated stuff into a "enriched" subclass of the bmp driver to keep things simple for "standard" bmp-users.

 

BTW: In the doc of the bmp it should also be remarked that the I2C adress is fixed to 0x77 and cannot be changed with any slave parameter.

 

Andreas

[trouch]

Thanks for giving precisions. I have to admit I did not searched so much.

I will add another optional parameter in the BMP085 to reference another temperature sensor.

Then use it in __getPascalAtSea__ if given, or use the bosh formula else.

I seen my mistake about slave address while copy-pasting doc pages, I have to correct it too.

--

[trouch]

BMP085 / Pressure codes update in r1127

see https://code.google.com/p/webiopi/wiki/BMP085

thanks for your help Andreas

[zm3...@gmail.com]

Hi,

adding the interface for mcp3x0x is a great idea and I really appreciate it. 

I checked out the latest code from svn today and tried to run a simple code

#!/usr/bin/python

import webiopi

from webiopi import deviceInstance

from webiopi.devices.analog import MCP3008

mcp = MCP3008(chip=0)        

print "# of channels = ",mcp.analogCount()      

print "analog max    = ",mcp.analogMaximum()    

print mcp.analogReadFloat(0), mcp.analogReadVolt(0)

print mcp.analogReadFloat(1), mcp.analogReadVolt(1)

print mcp.analogReadAll()

and I got zero's as an output.

# of channels =  8

analog max    =  1023

0.0 0.0

0.0 0.0

{0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}

I must be doing something wrong because I should be getting non-zero readings from channels 0 and 1.

I verified it with a separate code that doesn't use webiopi.

can you tell me what I am doing wrong?

Thanks!

[Andreas Riegg]

Perfect, this is a very flexible solution right now.

There is a little typo on the bmp085 wiki page, the line

bmp = BMP085(altitude=100, external:tmp)

should be

bmp = BMP085(altitude=100, external=tmp)

Andreas

[trouch]

MCP3008 works fine on my side with both python 2.7 and 3.2 :

pi@raspberrypi ~ $ more test.py 

#!/usr/bin/python

import webiopi

from webiopi import deviceInstance

from webiopi.devices.analog import MCP3008

mcp = MCP3008(chip=0)        

print "# of channels = ",mcp.analogCount()      

print "analog max    = ",mcp.analogMaximum()    

print mcp.analogReadFloat(0), mcp.analogReadVolt(0)

print mcp.analogReadFloat(1), mcp.analogReadVolt(1)

print mcp.analogReadAll()

pi@raspberrypi ~ $ sudo python test.py 

# of channels =  8

analog max    =  1023

0.0 0.0

0.50146627566 1.65483870968

{0: 0, 1: 513, 2: 485, 3: 40, 4: 34, 5: 511, 6: 0, 7: 1023}

I will check again with a fresh install...

What's your distro ? How is your MCP connected to the Pi ? Have you well wired RPi CE0 to MCP EN ?

[Stuart Marsden]

I have been travelling for work for a while so not had a chance to play. I have just tried the ds2482 i2c to onewire chip.

Getting it to work with webiopi is quite straight forward. I define the onewire devices in the config in the usual way.

Need to have the i2c_bcm2708 i2c_dev modules loaded. I then determine the i2c address of the ds2482

sudo i2cdetect -y 0 (or -y 1 for the new version)

I get:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 

10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- -- 

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

70: -- -- -- -- -- -- -- --                         

So I know the address is 18

I then:

sudo modprobe ds2482

And finally I need to tell the driver what address the ds2482 is on by:

echo ds2482 0x18 | sudo tee -a /sys/bus/i2c/devices/i2c-0/new_device 

The configured devices are now accessible in the normal way so if I start webiopi I get my temperature sensors that are wired off the ds2482 showing up as planned in the devices. However w1-gpio is loaded for no reason wasting GPIO 4.

I would suggest it should be a configuration setting something like:

oneWireModule = w1-gpio

oneWireModule = ds2482 0x18 #Change to actual i2c address

oneWireModule = none #For those who want to load themselves maybe through /etc/modules

It would also be possible to use w1-gpio and ds2482 at the same time.

Now I need to look at my ds2408 driver which seems to be broken. I guess the classes have changed and writeInteger has been renamed as I get this error when starting up:

2013-03-26 21:09:09 - WebIOPi - ERROR - 'DS2408' object has no attribute 'writeInteger'

Thanks for all the work looking forward to the next release.

[zm3...@gmail.com]

Thanks for response.

I tried with a fresh install but I still see the same problem.

I'm using rasbian with RPi rev2.

It's possible that my wiring is not correct for your code to communicate with mcp3008 correctly.

Here is my mapping

MCP3008 CH -> GPIO 

MCP3008 VDD -> 3.3V

MCP3008 VREF -> 3.3V 

MCP3008 AGND -> GND 

MCP3008 CLK -> #18 

MCP3008 DOUT -> #23 

MCP3008 DIN -> #24 

MCP3008 CS -> #25 

MCP3008 DGND -> GND 

I appreciate if you tell me how I should connect MCP to RPi correctly.

Cheers,

[trouch]

Thanks for this one Stuart !

I've received a RPIDOM board which includes a I2C to 1-Wire bridge.

But I didn't take time to try it yet, I'm focusing on 0.6 release.

You are right, I have to fix your DS2408 driver. writeInteger has been renamed to portWrite and readInteger to portRead.

I forgot this one on your driver. Thanks for pointing this.

[trouch]

zm3n79, you have to wire MCP CS to RPi CE0 (Pin #24), pin 25 is a ground.

Give up a try then please report here.

[Stuart Marsden]

The only problem I could see is that I called self.writeInteger(0x00) in the __init__ to set things to 0.

I have tried changing this to self.portWrite(0x00) and this seems to allow normal initiation. I have taken my ds2408 out of my chip holder so that I could try the ds2482 so cannot check the other functions at the moment but they should work. I will swap it back tomorrow and wire it up to ensure it works.

Stuart

[zm3...@gmail.com]

On Tuesday, March 26, 2013 3:28:39 PM UTC-4, trouch wrote:

zm3n79, you have to wire MCP CS to RPi CE0 (Pin #24), pin 25 is a ground.

Give up a try then please report here.

I think I confused you as I used the GPIO pin notation while you thought I used pin#. 

From now on I will use the pin#.

I wired MCP CS to Pin#24 but it is still doesn't work.

Here is my detailed mapping using the pin#

MCP3008 CHANNEL  -> PIN# 

MCP3008 16 - VDD    ->  1 - 3.3V

MCP3008 15 - VREF  ->  1 - 3.3V 

MCP3008 14 - AGND ->  6 - GND 

MCP3008 13 - CLK    -> 12 - PCM_CLK 

MCP3008 12 - DOUT -> 16  

MCP3008 11 - DIN     -> 18  

MCP3008 10 - CS      -> 24 - CE0 

MCP3008  9  - DGND ->  6 - GND 

[trouch]

MCP DOUT => Pi MISO (Pin #19, GPIO-10)

MCP DIN    => Pi MOSI (Pin #21, GPIO-9)

MCP CLK   => Pi SCLK (Pin #23, GPIO-11)

MCP CS     => Pi CE0 (Pin #24, GPIO-8)

see http://elinux.org/Rpi_Low-level_peripherals

which working code do you use ?

[zm3...@gmail.com]

I wired mcp3008 the same way as you described, I just checked out the trunk version from svn repository and I'm using the following script

#!/usr/bin/python

import webiopi

from webiopi import deviceInstance

from webiopi.devices.analog import MCP3008

mcp = MCP3008(chip=0)        

print "# of channels = ",mcp.analogCount()      

print "analog max    = ",mcp.analogMaximum()    

print mcp.analogReadFloat(0), mcp.analogReadVolt(0)

print mcp.analogReadFloat(1), mcp.analogReadVolt(1)

print mcp.analogReadAll()

but all I'm getting are bunch of zeros. 

It is puzzling me because the other script that I'm using (that doesn't require webiopi) works just fine (see attachment)

[trouch]

My mistake while writing my previous mail, it was starting to be late...

I inverted input and output, sorry.

The correct wiring is :

MCP VDD  (16) => RPi 3.3V

MCP VREF (15) => RPi 3.3V

MCP AGND (14) => RPi GROUND

MCP CLK  (13) => RPi SPI SCLK (GPIO-11  Pin #23)

MCP DOUT (12) => RPi SPI MISO (GPIO-9   Pin #21)

MCP DIN  (11) => RPi SPI MOSI (GPIO-10  Pin #19)

MCP CS   (10) => RPi SPI CE0  (GPIO-8   Pin #24)

MCP DGND ( 9) => RPi GROUND

This is actually exactly the same wiring as your other program :

# SPI port on the ADC to the Cobbler

SPICLK = 11

SPIMISO = 9

SPIMOSI = 10

SPICS = 8

How long is your wiring ? May be I set a too high speed...

This is very confusing me, I will release 0.6 today...

[Andreas Riegg]

Eric,

 

one more urgent small thing that should find its way to 0.6 ....

 

In the method that calculates pressure at sea level is a division by k:

 

def getPascalAtSea(self):

pressure = self.__getPascal__()

if self.external != None:

k = self.external.getKelvin()

return float(pressure) / (1.0 / (1.0 + 0.0065 / k * self.altitude)**5.255)

return float(pressure) / (1.0 - self.altitude / 44330.0)**5.255  If for some reason k is 0 (maybe due to some sensors errors or default responses that deliver 0) we will get a division by zero error. So you could add some check against k != 0 to prevent this and fallback to the calculation without k. Good luck with your last steps to 0.6 and I'm really curious to see which impact 0.6 with its now really broad device driver suite and very easy installation comfort will have on the Raspi community. Andreas

[Trouch]

Good point Andreas ! I will fix it.

Thanks you very much for your support.

I'm also very curious of the welcome 0.6 will have. I hope a better highlight to be honnest ;)

After my working day : PiStore packaging & testing, final wiki update and release with a blog post.

[Stuart Marsden]

Have wired up my ds2408 again and can confirm it works fine with the latest svn with the initialisation fix. Good to go for 0.6.

Stuart

[Robert More]

Both scripts work on my end.

[trouch]

Thanks Robert to confirming it works ! 

Can I ask on which board revision you got it working ?

[Robert More]

Processor       : ARMv6-compatible processor rev 7 (v6l)

BogoMIPS        : 464.48

Features        : swp half thumb fastmult vfp edsp java tls

CPU implementer : 0x41

CPU architecture: 7

CPU variant     : 0x0

CPU part        : 0xb76

CPU revision    : 7

Hardware        : BCM2708

Revision        : 000e

Serial          : 00000000b8xxxxxx

[trouch]

Okay, this is a REV2 board, one of the latests.

Thanks.

[zm3...@gmail.com]

I figured that your input/output was reversed and that's why I fixed it. 

I just uploaded v0.6 and I still read zeros while my other script attached in my previous post is working fine.

Not sure where to go from here.

[zm3...@gmail.com]

The problem is solved. I discovered that my script interferes with your code. When I run my script first (after the reboot) your code returns 0s on all the channels. However, if I do a clean reboot and run script using webiopi first than everything is working just fine.

I appreciate your help!

[trouch]

Hard to find out !

Happy you solved the problem by yourself.

[trouch]

Stuart,

I've tried your tip for ds2482, it works great !

I'm now thinking about a way to ease setup with webiopi.

Something like what you suggested.

Eric.