ESP32: Hall effect sensor

[carefulcomputer]

Have you looked for this feature in other issues and in the docs?
Yes

Is your feature request related to a problem? Please describe.
ESP32 includes a hall effect sensor. I don't see a way to read the value.

Describe the solution you'd like
It will be great for tasmota to read the value and be able to make it available (I will be sending it over MQTT if it exceeds a threshold using rules),

Describe alternatives you've considered
None

Additional context
None

(Please, remember to close the issue when the problem has been addressed)

[Staars]

Just out of curiosity, what would your hardware setup look like?

I did a quick and dirty proof-of-concept driver to see the behaviour of the sensor. After applying a (Kalman) filter the readings are quite stable and I could sense a magnet through a piece of wood (like a table).

The graph shows the values with and without the filter (multiplied by 100). I am still playing ...

[carefulcomputer]

i have an esp in garage to track/control my garage door/garage lights/parking sensors/mailbox. Since esp is housed near doorbell transformer, planning on using the hall effect sensor to detect doorbell ringing and send notifications.

[Staars]

If you are still interested, here is a test version: https://gist.github.com/Staars/09c24fe92880c5453d719df0372ee812

Just replace the file inside Tasmota and compile for ESP32.

There are a few things, that could be done differently. So I multiplied the measured hall sensor value by 10, after applying the filter, which be or may not be useful.

RULE would work like this: on ANALOG#Hall>100 do...endon

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[samuelalexmclean]

Thanks stalebot, still a valid FR.

[sfromis]

Did you try the test version posted by Staars?

[samuelalexmclean]

Yup, worked for me. I was hoping this might become part of the main branch as a first class compile customization. Is that likely or is this a bit niche?

[Staars]

If we find a niche in the source code ... 😁

We will do some internal talks about it. This demo driver binds the hall sensor to the ADC-driver, which would make sense for me. An extra driver would be overkill for my taste. I guess there is a chance to include this, as the ESP32 is no too space limited and it is a built-in chip feature.

Was the scaling okay for you? It was just a spontaneous decision and later I thought it might be better to go down by a power of ten.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ErnieFR]

If you are still interested, here is a test version: https://gist.github.com/Staars/09c24fe92880c5453d719df0372ee812

Just replace the file inside Tasmota and compile for ESP32.

There are a few things, that could be done differently. So I multiplied the measured hall sensor value by 10, after applying the filter, which be or may not be useful.

RULE would work like this: on ANALOG#Hall>100 do...endon

How did you know the sensor was called "analog#hall" in Tasmota? I can't find any description of this sensor in the Tasmota docs, other than enabling gpio36 and gpio39 for halleffect-1 and halleffect-2. The sensor works allright, but if I try to publish it, nothing happens and I suspect that a rule like "on ESP32#halleffect#state do publish bla bla bla endon, is wrong syntax? Although looking at the payload in the console of the Tasmota hello-message it says : "19:50:42.034 MQT: tele/tasmota_FC6434/SENSOR = {"Time":"2024-01-14T19:50:41","ANALOG":{"A1":2279},"BME280":{"Temperature":27.9,"Humidity":28.8,"DewPoint":8.1,"Pressure":980.8},"ESP32":{"Temperature":38.9,"HallEffect":-6},"PressureUnit":"hPa","TempUnit":"C"}" ==> publishing the halleffect value by "tele-ESP32#halleffect works fine! So I don't get it...

[barbudor]

Because staars added that mode into that modified file, it's not part of standard Tasmota code base Note that this file is now very old and copying it roughly into current Tasmota wmay not work, or even prevent compiling

[ErnieFR]

Because staars added that mode into that modified file, it's not part of standard Tasmota code base Note that this file is now very old and copying it roughly into current Tasmota wmay not work, or even prevent compiling

Hey Barbador, how are you? Nice to see somebody is alive here :-) great. Found out the right syntax only don't understand why a rule does not react with "on ESP32#halleffect#state" as trigger

[Staars]

Note the date: created this gist on Sep 13, 2020.

I will delete this very old GIST, it is confusing at best nowadays.

[ErnieFR]

Note the date: created this gist on Sep 13, 2020.

I will delete this very old GIST, it is confusing at best nowadays.

THANKS at least that's solved !

[barbudor]

@Staars May be it could be usefull to update that code and merge it ?

[sfromis]

The standard built-in Hall effect support (different from what Staars did) is indeed ESP32#HallEffect, as you can see based on the SENSOR payload published, and also printed in the console. .../SENSOR = {"Time":"2024-01-14T19:57:49.992+01:00","ESP32":{"HallEffect":-28}}

[Staars]

@barbudor I assumed, that my old (and forgotten) demo code is not needed anymore as this is now integrated as @sfromis pointed out.

[ErnieFR]

The standard built-in Hall effect support (different from what Staars did) is indeed ESP32#HallEffect, as you can see based on the SENSOR payload published, and also printed in the console.

Hey Sfromis, did not know I was being watched so closely :-) But can you tell me why this does not work please : rule3 on esp32#halleffect#state do publish domoticz/in {"idx":190,"nvalue":0,"svalue":"%value%"} endon rule3 on ==> I have a SG90 servo on a gpio pwm output, it changes position with a little magnet on its arm near the Wemos-Lolin On the main Tasmota screen, the value changes accordingly but that seems not to activate the trigger above...

[ErnieFR]

https://github.com/arendst/Tasmota/assets/60966258/2ab77575-2a82-49e0-a724-e662305bb14e

Here's little demo, if you think I should not do stuff like this here on github but rather do this at DiscordApp, please let me know. I do not want to do something wrong here.

[barbudor]

Oh, that's for th ESP32 internal Hall sensor ? I thought it was about an external one connected to an analog input

[barbudor]

@ErnieFR Discussion is fine but not a good idea to dig up old discussion Better to start a new one if you want

Discussion or Discord is up to you

[Staars]

Only the built-in one. What a lost code snippet can bring up 😁 . (No problem, but now let's close this)

[sfromis]

rule3 on esp32#halleffect#state do means that you are not using the suggested ESP32#HallEffect. Having #state is only relevant for certain types not appearing in JSON, and only as specifically suggested in the docs. The JSON parsing is very generic, and there #state is not relevant.

[ErnieFR]

rule3 on esp32#halleffect#state do means that you are not using the suggested ESP32#HallEffect. Having #state is only relevant for certain types not appearing in JSON, and only as specifically suggested in the docs. The JSON parsing is very generic, and there #state is not relevant.

Okay thanks for explaining that, I'll keep using "on Tele-ESP32#halleffect " then, it seems that there is always a few seconds delay anyway before the Hall Effect sensor shows the right value. The min logging of 10secs simply forces me to wait for the right value. Good thing I'm retired, haha. Cheers

[s-hadinger]

Please keep in mind that Espressif is dropping support for the internal Hall effect. So it will soon be not available anymore.

[sfromis]

I'd expect the feature to stay in the first ESP32 series (along with Ethernet support), but indeed not in the newer ESP32-Sx/Cx/Hx/whatever. And it's usually not a great spot for a hall effect sensor, anyway.