Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a 24GHz mmWave Sensor - Human Static Presence Module as switch #2593

Open
oxivanisher opened this issue Oct 8, 2023 · 2 comments
Open
Labels

Comments

@oxivanisher
Copy link

oxivanisher commented Oct 8, 2023

Device

D1mini with soldered on bh1750 and the mmwave sensor

Version

Current dev branch (3a34f06)

Question

Hi all :)

My usage of espurna in this case is to detect if a room is occupied and get a normalized lux reading to then trigger lights. The espurna device is only reporting everything to MQTT, all the logic is done within node red.
I used almost the same setup for years with old PIR sensors, but the PIR sensors are triggering every ~30 seconds if movement is detected. The mmwave module on the other hand has complex outputs which can detect a lot of different things, but I am only interested in the simple output on pin S1: high level - occupied, low level - unoccupied.
It works like my following configuration somewhat, but I am sure the configuration can be done better. Only the bh1750 and the mmwave sensor are connected to the D1 mini. I started with the example on the buttons and switches page.

My questions are:

  1. Do I need a relay configuration at all for this usecase? I tried it without, but it did not seem to work. But maybe I changed something else I am not aware of or I don't understand the relation between relay and switch. 🤷‍♂️
  2. I get a "pressed" event when the sensor detects a person, but I did not get "released" events without setting BUTTON_MQTT_SEND_ALL_EVENTS to 1. I am pretty sure my switch config is not as it should be.
  3. Since node red can lose its state of the presence sensor, is there a way to query the button state or to re-transmit the current state regularly? I get the keep alive messages, but they don't contain the switch state.

Also I created a 3d printed case for this whole setup and I am gladly sharing everything, if somebody is interested. Once it works as expected I can make a PR with my settings here, or document it all on printables.com where I will upload the case.

code/espurna/config/hardware.h

#elif defined(WEMOS_D1_MINI_PRESENCE_BH1750)

// Info
#define MANUFACTURER "WEMOS"
#define DEVICE "WEMOS_D1_MINI_PRESENCE_BH1750"

// Buttons
// No buttons on the D1 MINI alone, but defining it without adding a button
// dosn't create problems
#define BUTTON1_PIN 0  // Connect a pushbutton between D3 and GND,
// it's the same as using a Wemos one button shield
#define BUTTON1_MODE BUTTON_SWITCH | BUTTON_DEFAULT_LOW
#define BUTTON1_RELAY 1

// The switch should send pressed and released, but i did not get released to work without this:
#define BUTTON_MQTT_SEND_ALL_EVENTS 1

// Relays
#define BUTTON2_PIN 5
#define BUTTON2_RELAY 0
#define BUTTON2_MODE BUTTON_SWITCH
#define BUTTON2_PRESS BUTTON_MODE_ON
#define BUTTON2_CLICK BUTTON_MODE_OFF
#define BUTTON2_DBLCLICK BUTTON_MODE_NONE
#define BUTTON2_LNGCLICK BUTTON_MODE_NONE
#define BUTTON2_LNGLNGCLICK BUTTON_MODE_NONE

// LEDs
#define LED1_PIN 2
#define LED1_PIN_INVERSE 1

// When Wemos relay shield is connected GPIO5 (D1) is used for relay,
// so I2C must be remapped to other pins
#define I2C_SDA_PIN 12  // D6
#define I2C_SCL_PIN 14  // D5

code/platformio.ini

[env:wemos-d1mini-presence-bh1750]
board = d1_mini
build_flags = -DWEMOS_D1_MINI_PRESENCE_BH1750 -DDEBUG_FAUXMO=Serial -DNOWSAUTH -DBH1750_SUPPORT=1

connection table

  • Using the seedstudio mmwave static pressure sensor
  • The Mmwave sensor has a 8 and a 6 pin plug. We use the 6 pin Plug for connection.
Wemos D1 Mini Connected to
5V Mmwave 5V (top left)
GND Mmwave GND (top right)
D1 Mmwave S1 (bottom left)
3.3V BH1750 VCC
GND BH1750 GND
D5 BH1750 SCL
D6 BH1750 SDA
@mcspr
Copy link
Collaborator

mcspr commented Oct 16, 2023

Do I need a relay configuration at all for this usecase? I tried it without, but it did not seem to work. But maybe I changed something else I am not aware of or I don't understand the relation between relay and switch.

I get a "pressed" event when the sensor detects a person, but I did not get "released" events without setting BUTTON_MQTT_SEND_ALL_EVENTS to 1. I am pretty sure my switch config is not as it should be.

Only important thing is some action attached to event. MQTT publish never happens unless there is some action or BUTTON_MQTT_SEND_ALL_EVENTS is 1 (or, the setting btnMqttSendAll / btnMqttSendAll<button index starting from 0> for individual buttons)

#if MQTT_SUPPORT
if ((action != ButtonAction::None) || _buttons_mqtt_send_all[id]) {
mqttSend(MQTT_TOPIC_BUTTON, id, String(_buttonEventString(event)).c_str(), false, _buttons_mqtt_retain[id]);
}
#endif

Relay action would use relay ID, but it does not check whether it is a valid one or even exists

Since node red can lose its state of the presence sensor, is there a way to query the button state or to re-transmit the current state regularly? I get the keep alive messages, but they don't contain the switch state.

Have you tried digital sensor? State would be periodically published with the other sensor data.

For sensor data we have an extra report condition when value changes by some absolute value. e.g. set digitalMaxDelta0 1 and reload in terminal would set it up to publish every time 1st digital sensor value changes by 1 (i.e. 0 to 1, and 1 to 0; since sensors use numeric values)

@oxivanisher
Copy link
Author

Thank you very much! This seems to be what I was missing.

I am getting this correct, that it only triggers when i query the sensor (so I check for it every second) and that the "retransmit" on the MQTT side is meant to be solved with retained messages?

All in all it works better that my solution at the top.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants