Hello together!
I wish I could connect a magnetic sensor to the GPIOs and push the status together with other data to Grafana. The hardware part is not a problem but my poor programming skils are not enough to change the FW properly. I have installed Segger Studio, but I couldn’t find a way to implement such change. Can someone help me with this please?
Hello,
What kind of change there should be in data once the magnetic sensor is activated? Are you looking for something like movement counts, or just one bit to signal that the magnet is activated right now?
How you will parse the data?
Hello Otso,
Many thanks for you reply. Unfortunately the movement counter doesn’t work reliable in my case. Gives me a lot of false alarms. I’m looking for a one bit changing depends on the sensor state. The idea is to trade one variable, which I never use (like "Dew Point), for such one bit signal, which I could represent in Grafana.
I believe such sensor should be perfect for this application:
Hope this answer your question.
Dew point is actually calculated from humidity and temperature data, it is not sent from sensor.
You could duplicate the button code and use the hall sensors as a button. Then you could use button interrupt to increment the movement counter instead of using accelerometer interrupt there.
Looks like a great little part 2mm x 1mm x .4mm, 48uA(average), . $.27 (@ 5,000! digikey), dumb interface to GPIO (1 for sense (maybe 1 for enable allowing 1 uA))
Might want 10nF capacitor.
We need to know more about your application.
If you are doing something like counting revolutions, conditions may be changing quickly (bicycle wheel) or not (water wheel). Might need to be interrupt driven.
What about accuracy? If you miss a change you can still know the RPM. What if the value is wrong? If you are counting objects that pass, what if you miss one?
Are you concerned about the state of the magnet. For example is the window closed.
What do you want transmitted? The number of changes (since last report (not a good idea for unreliable bluetooth packets) or per unit of time) or the current state?
++++++++++++++++++++
Regarding where to put a single state value in the packet, one idea is to use the least significant bit of a field you don’t care about. For example in format 03, byte[3] holds hundredths of a degree centigrade with a maximum of 99. If you don’t care about that degree of resolution, jam a 1 (by ORing a 0x01) into that field to indicate presence (which 50% of the time will increase the temperature reported by .01°C) and clear the lowest bit by ANDing with 0xFE (which 50% of the time will decrease the temperature reported by .01°C.
Another more incompatible idea is to use the range over 99 (in the case of the temperature). For example if the sensor is present add 100. The result is that values over 99 are indicate presence, values 99 or less indicate not-present. This has the disadvantage of confusing existing receiver applications like RuuviStation and RuuviCollector, but may be easier to display with Grafana by simply dividing by 100.
Many thanks for your interesting reply.
Well, my application is very simple, just to check if a door is closed. The best would be to transmit just the sensor state - a one bit value every cycle, nothing fancy. It is not a critical application, even the simplest solution would work for me. Unfortunately I couldn’t figure out how to do this anyway.
I think the best would be if somebody could prepare a working solution for me for some extra money.
Is somebody willing to help me with this please?
Easiest way to find some help with your project would be on the matchmaking section of the forum: https://f.ruuvi.com/c/matchmaking/help-needed
Hello Otso, Dgerman,
Thank you very much for your time and the advice.
I have just created this topic:
Actually that is a fantastic idea. I have just played around with RuuviTag and ioBroker (smart home) and this would be a great solution to monitor doors opening and closing.
I also recently installed a smart door sensor at home. The problem with available smart door sensors for Wifi is that they are not online all the time like traditional smart devices. They are in OFF/power saving state when there is no activity, and only when a door opens and closes they will connect to the network and tell whatever is controlling them (usually smart home app/server) that something happened. They do this to preserver battery. Tasmota firmware is theoretically compatible and can be programmed, but it won’t work on these battery powered devices (known limitation and no work around due to how “power saving” works).
These smart door sensors are therefore very unreliable because they are slow (to connect), rely on (1) local wireless network, (2) the internet and (3) a “smart server” by the manufacturer somewhere (possibly at the other end of the world). A lot can go wrong between door sensor and server and it shows on a daily basis when in use. In my case I simply turning on a light when the door is open, but trust me when I say it often fails and I am not the only one complaining about the same issues.
RuuviTag with BLE would be a real good solution if somebody could get this to work with the sensor above.