-
• #2
Cool! I have one lying around here and will soon try your code out with it and hopefully find some time to give feedback here!
-
• #3
Looks great! Sadly I don't have one to test with, but when it's working could we add it to the standard Espruino modules?
-
• #4
Yeah, sure... I'll do a pull request if #kai or someone else can help test it with another sensor. I've also got a barometric sensor and a humidity/temperature sensor to do the same way.
It'd be nice to get the usual popular Adafruit etc. breakout sensors ported, especially if done to a reasonably consistent API.
Tom
-
• #5
Yes, that'd be awesome. There's some code on here somewhere from someone who got the humidity/temp working - but no module for it.
I'm going to try and come up with a template module soon though, because if you can put all the constants in a variable that's private to the module then when the module is minified it gets a lot faster and uses up an awful lot less RAM (while still being as readable as yours is :) ...
-
• #6
Of course there needs to be a delineation between public constants needed for configuration (eg. tsl.C.address.FLOAT) and private constants used internally.
Alternatively, to use a better way of configuring than using a bunch of pseudo-enums.
BTW, one thing I did notice (but didn't have time to investigate last night) was the problem of chaining calls, eg.
obj .init(foo, bar) .setFoo(1) .getValue(function (val) {...});
rather than individual statements. The interpreter (or IDE... can't remember which) seemed to bork on the syntax.
-
• #7
Hmm. Could you try and come up with a really simple bit of code that fails, and stick it on https://github.com/espruino/Espruino/issues ?
This sort of thing does work though:
>function a() { return { a : function() { return 42; } } } =function () { return { a : function() { return 42; } } } >a().a() =42 >a().a(function (val) { }) =42
Good point about the public constants, I'll make sure I think about that.
-
• #8
Will do. I meant to investigate it and file an issue last night, but the yawning started.
-
• #9
Following up on this thread... there's an issue at https://github.com/espruino/Espruino/issues/211
Incidentally, I've refactored the TSL2561 code somewhat and fixed a few bugs. It should use memory more efficiently now. https://github.com/tomgidden/espruino-misc/blob/master/tsl2561.js
-
• #10
Thanks!
Could you do a pull-request on http://www.github.com/espruino/EspruinoDocs with it as a module (and maybe a very quick markdown file showing its use)? Either that or I could do it...
-
• #11
Will do, but I'm not sure it's ready yet. I'd like to get the Lux calculation done, plus verify that the main code's working correctly as I'm still not getting a reading off the infrared channel, even after I double-checked the code against the original datasheet.
EDIT: Well, I guess it doesn't need the Lux calculation, but I'm still concerned about the infrared readings. Incomplete is one thing; broken is another matter entirely.
Tom
Hey,
I've got a basic module for the TSL2561 luminosity sensor as sold by Adafruit done. It's pretty much a port of the Arduino library. It's not complete, and it's not fully working (which may or may not be a problem with my code or my specific sensor) but it's certainly sensing changes of light for me.
Anyway, thought I'd mention it as it shows a reasonably neat abstraction of an I2C-based sensor with an asynchronous read callback...
https://github.com/tomgidden/espruino-misc/blob/master/tsl2561.js
Tom