I have a question. I have Core Module, Tag Module and Battery Module, all in R1.3. I connected following tags: Lux R1.1, Barometer R1.1, Temperature R1.2 and Humidity R1.1 and R2.1.
I uploaded latest bcf-kit-wireless-climate-monitor firmware. Every tag works except Humidity. I’ve tried one by one and neither revision of Humidity tag works for me. Is there something I could “tune” in the firmware source code to make it work? I would like to reuse this older and bigger version of climate module from the beginning of the BigClown project. Is it even possible with the latest firmware?
Also I noticed that battery module reports 0.0 value even I put fresh batteries inside.
Ok, understand I didn’t realize that climate firmware can be used only with kit, now I know… Thanks to your hints I was able to modify bcf-sdk and bcf-kit-wireless-climate-monitor accordingly and now everything works.
I briefly checked the source code of generic-node firmware but it seems to me it’s doing more than I actually need (I don’t have LED strip & CO2). But at least I was able to find how to initialize humidity sensor properly.
Yes, you’re right it’s not good to make changes directly into SDK. It was just a quick hack, I just wanted it to work…
Originally I thought I would copy the bc_module_climate logic from SDK into my application.js and update the part I need for humidity. I will see, once I have some time I will improve it so I can use “pure” SDK…
Regarding the SDK, do you think it make sense to have logic for particular “kit” configuration hardcoded there? To me it looked strange on the first sight. Also there are defined I2C addresses for tags inside the SDK but you than need to know them in you application because you will use them for publishing (so you have to first look inside source code of SDK to know the addresses, it was confusing for me)… Maybe it would be better to have climate module more generic or configurable. What do you think?
Our plan in future is to create a generic firmware, which will be configurable by computer to what the node should send, when and which sensor will initiate that transmission. Right now it is not possible to create a universal implementation of for example accelerometer alarm.
One of the reason that each kit has its own project and code is simplicity. The generic-node firmware is too complex a generic for everyone to start with it or change a single thing. By creating kits with minimal firmware it should be easier to change something or improve the code a bit.
In our SDK, there is not hard-coded kit. The modules are “hard-coded” but if you take a look closer on sensor module, it’s just a wrapper for a sensors that are contained on the module.
Yes, I agree that generic but configurable firmware would be great That’s what I hope for.
I have no problem with separate project per kit. That’s actually really great. My problem was when I was searching for a place where I need to put a different revision of humidity sensor. Because I wanted to preserve the rest of the logic/code in the climate kit.
I would expect sensors, revisions and I2C addresses to be inside of the kit’s related project, not in SDK. That’s my only concern. IMHO SDK should only contain generic functions you can use in a project. Do you know what I mean?
But maybe there is also difference between a kit and a module which I cannot see.