Hello,
I’m looking for somebody who can implement a Hall effect sensor into the Ruuvi firmware. The use cese is just to monitor door open/close state using a magnetic sensor connected to GPIO in a way that I could represent the state in Grafana.
The details can be consulted in this topic or Private Message.
Did you have any luck finding someone to assist with this project? I too would be interested in how to accomplish this.
Hello,
We’re planning to include official support for Hall sensor to 3.x branch Ruuvi firmware.
Can you be a bit more specific about your use cases, what exactly should happen on hall sensor being triggered?
Hi Otso,
It’s a really good news for me. Awesome.
My use case is just an object presence detection, for my simple application a Boolean value is enough. The value should be refreshed every tag cycle (I have heard some of low enegry hall efect sensors reports only a state changes to save energy).
A counter on sensor state changes could be even better solution since it allows to count fast pulses and no risk to miss a state change.
In this case should be possible to distinguish the magnet state:
I guess a sensor with analog output wouldn’t make sense with Ruuvi, because of the tag refresh rate.
Hello,
I think the movement counter field of data format 5 could be repurposed here, for example by incrementing movement counter on both acceleration event and hall event and using the last bit as activity ongoing / hall open bit.
Digital IO is pretty much required, interpreting analog value for each different magnet and positioning would be complex. In theory the same code which is used with buttons could be used here, as it’s a matter of having a pull-up and detecting when the hall sensor closes. Some care must be taken to not bleed the battery via pull-up if the hall sensor is closed most of the time.
So a tag is considered either stationary, in which case the movementCounter is movements going past it or it is moveable(even slightly) in which case movementCounter is the movements it makes( however small)
In my case it wouldn’t be a good solution since i get some false increments from ACC sensor (unwanted vibrations) and common counter would be rather problematic for presence monitoring tasks, where is needed to separate the ACC readings.
My suggestion is to implement in firmware a selector for MC counter, where one can choice if the counter should be taken from ACC, Hall or both sensors combined.
Good feedback, thanks 
.
Adding support for a hall sensor itself should be pretty straightforward, but the next question is how to handle the firmware variants in builds. We have already 4 boards with 4 firmware variants each, so the GitHub releases tend to get cluttered.
Selecting modes with buttons would be cumbersome and configuring the mode over GATT would be a lot of work. Of course it would be possible to a write one-off version similar to acceleration measurement firmware.
A great place to establish Configuration Information, changeable at deployment i.e. not at compile time, is in the User Configuration Information Register which can be modified using DFU. No special tools or source programming expertise required.
The UICR updated over DFU wouldn’t really bring advantages over hardcoded configuration, but configuring over GATT definitely would.
@Alex how is your schedule? We could do this as a consulting project at Ruuvi if you’re in a hurry, or we could wait until the Ruuvi Connector system is ready and we can add the support then.
I have some very small reed switches which fit into the ruuvi case. Could using these instead of the Hall effect sensor mitigate the “Some care must be taken to not bleed the battery via pull-up if the hall sensor is closed most of the time.” problem?
The reed switch has the same issue, if there is a pullup/-down in RuuviTag and the pin is driven to other state through reed switch there’s going to be a notable leakage current.
Might that leakage be reduced to an acceptable level by having the "sourcing " side of the switch connected to an output pin (example P0.30 ) (rather than to ground) which is only driven 1% of the time.
The best solution is to use a hall sensor with push-pull output so that there’s no pull-up/down needed. The second best solution is to disable the pull resistor when the switch is activated and poll the pin every now and then.
In general any leakage is not acceptable, the baseline consumption of RuuviTags is a few microamperes and even 1% of the (3 V / 13k ohm) is 2.3 microamperes, which would be the biggest single component in idle consumption.
Sounds like a good idea.
Hi Otso,
Thank you for your interest. I’m not in hurry, it’s just a hobbyist, not professional purpouse. I was looking how I can do this by myself but unsuccessfull. That’s why I’m more than happy to hear that the Ruuvi team is interested to help us. Really appreciate this.
BTW - The suggested method with power switch has some disadvantages and I woudn’t like to use it.
I wish I could help you somehow with this topic but I’m lacking knowledge on this field and have no other idea than being a beta tester or just send you a crate of beer 
Hi is this the ideal guy? … Digital Switch Omnipolar Switch Open Drain, Push-Pull Hall Effect SOT-23-3
https://www.digikey.com/product-detail/en/texas-instruments/DRV5032AJDBZT/296-47450-1-ND/7896943
and ideally, which pins or does anyone like to sugest a configuration (w cap/resis) + mounting position (not to hinder antenna)?
thank you
Looks good, personally I’d connect it to P0.13 which is already the push button pin. It should work right away if the model is open-drain.
In related news, the Ruuvi FW 3.x has now support for powering a HALL via GPIO and the Ruuvi Connector board is progressing nicely.
for Espruino users - best configuration?
@otso if I can gain confidence in the right configuration (guide) to add a hall inside a ruuvitag enclosure I’ll plan to integrate into a commercial application
