-
Notifications
You must be signed in to change notification settings - Fork 639
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
Using Wemos D1 mini with multiple GPIO inputs #1815
Comments
Each iteration of the events pin definition overwrites the last, but that would be the expected behaviour of the code. I.e: A = 1
|
So I can't use digital or events pin definitions for multiple GPIOs? I guess I could try multiple toggle switch definitions and make sure web GUI or mqtt doesn't change the switch state, just the 0/1 on the GPIO pins? |
I don't think you'd have too much of a latency issue using normal button/switch defines over mqtt, the only time I see any lag is from the sonoff pir/door switches connecting via the RF bridge - I usually make it to the bottom of the stairs before the light comes on. The T1's that I use in mqtt groups (additional units as slaves) all switch in around half a second or so. BUTTON_SWITCH will send an event on opening and closing, BUTTON_PUSHBUTTON will only send an event when it releases (so it might not work as desired). Pushbutton might also give you problems on certain gpio's when using n/c (I use a sonoff dual that's buried in the wall, and so occasionally I forget to switch off the light switches before restoring power to the light circuit. I've got connected to it's gpio... And it goes into programming mode every time 😆 Alternatively, there are a few Arduino based setups that might be more reliable, particularly if you can get it hard wired over Ethernet to your LAN. It should be feasible to use a really cheap spi based module, albeit at a fairly slow speed, which should still be plenty for mqtt. I've used them on rpi's in the past, and they worked first time as soon as spi was enabled ofc. I wish I had a hard wired alarm system. |
Thanks for the info. I'd planned to use BUTTON_SWITCH so I didn't have any issues with the long click etc. It would be nice to have the actual open/close state via mqtt but know SWITCH can't do that. For my application state toggle should be fine. I'll see how I get on and look at Arduino in the future if I want more capability. |
@mcspr @xoseperez |
I have tried with BUTTON_PUSHBUTTON for now, but the following config only gives one switch (Switch#0 at GPIO5).
Anyway, pulsing some of the pins to ground and open I get the following in the debug screen. I should be able to use the MQTT button=1 as a trigger.
|
Based on config, 5 buttons are linked to the single switch and expected behaviour is to release the switch when no buttons are pressed? Other issue has a PR linked that proposes sending pressed status instead of event, but not sure how that would work better - as a configuration for type of the thing that gets reported (event number or boolean pressed status), or additional action. Configuration naming too... |
Not quite. I want 5 GPIOs to monitor the state of 5 PIRs (which are NC contacts when no movement detected) and report OPEN/CLOSED using MQTT (and ideally show their status it the web GUI). OpenHAB would then use the state change of a virtual switch when the virtual alarm system is set as 'armed'. If the system is triggered, OpenHAB then switches Switch#0 on, activating the low level trigger relay and applying power to the sounder. After a time period or deactivation of Switch#0, the sounder goes off.
Playing around I saw that and made adjustments. All events now report their status to MQTT. Long and Longlong give 4 and 5 and when open gives 1. OpenHAB can then use, IF switch is NOT 1, no movement (OPEN or OFF), IF 1, movement (CLOSED or ON). I did have the odd event '6' appear. Not sure what state that represents? I also tried
Just looking at the Wiki, I assumed DigitalSensor would allow multiple sensors and report 0/1 for each one, but it only allows the one GPIO. I'll look at sensor.ino, but my coding knowledge is pretty limited. :-) |
Next step is to add RFID arm/disarm #1800! |
Sorry to reference code again, but that was triple click: espurna/code/espurna/config/types.h Lines 32 to 39 in 0998110
(which should probably be printed in the debug log, at the very least. maybe optionally, send this translation instead of evt number to mqtt) For multiple sensors, this needs to be duplicated per sensor (including curly braces): espurna/code/espurna/sensor.ino Lines 576 to 582 in 1d133be
espurna/code/espurna/sensor.ino Lines 469 to 476 in 1d133be
Which, again, could be configured via settings at runtime whenever DIGITAL_SUPPORT is on. Each header config option could get an index (a-la BMX280 config in the same method) |
@ColinShorts @mcspr I'll try and find some time at the weekend to modify sensor.ino and build using digital sensors again. It seems the best solution for my project. |
And multiple entries in sensor.h file?
etc... |
Last piece of the puzzle. MQTT will only show the digital states with respect to the refresh rate set in the sensor tab of the web GUI. If a sensor goes 1 to 0 and back to 1, MQTT dosen't post that state unless the state is at 0 during its refresh cycle. Is there another setting is sensor.ino to report to MQTT on state change like the |
I wonder if The only strange issue is that Count#3 says its @GPIO3, but is set to 13 in custom.h?
|
DigitalSensor is reading every sensor read interval, unlike EventsSensor. Note that with recent change I tried to speed up events processing by removing immediate callback call and caching it for a bit. Hope that works ok (including debounce time, my main worry are missing values) Digital one could have the same trigger mechanics, imitating the buttons pin reader with some modifications |
Probably a maximum of 1 second. Doing a 'walk test', three out of the five show MQTT state changes on every trigger (1) and then 0 when not triggered. I think I need external pull up resistors for the other two PIRs. I'll look to try that this weekend. |
All five PIR's are now working with pull up resistors. A few lines from debug are below, but all Sensors#0-4 give the correct outputs when triggered. Thanks again for all your help.
|
@davebuk I'm trying to get the Wemos PIR shield working on a Wemos D1 Mini with the following config:
The PIR is HIGH on GPI0 (D3) when motion is detected. However, the interrupt is not getting triggered with motion:
Any ideas? |
I don't know of a specific reason, the only thing I have set differently is to enable |
I'm surprised it uses GPIO0 as if that pin in low at boot, the device is being put into flash mode. I don't build using the flags, I use platformio with a custom.h file and build using |
What is the expected message I should be seeing? A button sensor log? |
AFAIK the button events flag you have set is for any configured buttons, not the event sensor you have added. Looking at my output i the debug screen: #1815 (comment) You could test the wemos GPIO pin by having the PIR disconnected for now and using a piece of wire to pulse your GPIO to the GND pin or the 3V3 pin and see what happens. Do you have a status page similar to mine: #1815 (comment) When my PIRs go from LOW to HIGH (NC or open circuit) the count goes up on the status page for that configured GPIO. |
The other thing, https://github.com/xoseperez/espurna/wiki/Sensors#counter-sensor states the default trigger is 'rising'. I changed mine in custom.h to use 'change' (not 'both', think wiki is wrong) so it reports all triggers. |
I've removed the PIR shield and pulsing GPIO0 to GND gives me some interesting results. Is it normal to crash the Wemos if I keep the "pulse" long enough (e.g. 2 seconds)? Sometimes only a
With the PIR shield installed, every time there is motion, the Wemos crashes (cc @mcspr):
|
See: espurna/code/espurna/config/hardware.h Line 98 in 274f71d
All default builds of wemos devices set GPIO/D3 as a button1. Long press will trigger button events. I would change the GPIO pin used on your PIR board to another one and configure wemos accordingly. |
I have problem activating digital input/event in 1.14.1 version. I have edited arduino.h and sensor.h but digital inputs are not shown in web interface. Is there any steps I missed?
`
|
From those config files above, I would say it looks like you have enabled the following functions.
I think the problem is the Try either editing |
I would tend to use just the |
Note of the 1.15.0 function of
|
I tried with "#define EVENTS_SUPPORT 0" and even changed EVENTS1_PIN but still Digital pin state is not shown on web interface! |
@bluexp1 if you go to the DEBUG panel, and type |
@mcspr I received nothing in debug panel, but in serial terminal I got a "+OK". |
@bluexp1 should be |
@mcspr it is really strange, cause I already have "#define DIGITAL_SUPPORT 1" in both arduino.h and hardware.h!!! |
@bluexp1 my only other guess is to use |
@mcspr Thanks, I added it to hardware.h and it worked! |
I have a D1 mini and plan to use it with MQTT and openHab as the main hardware interface for a house alarm system. The idea is to have the currently installed hard wired PIRs feed their N/C outputs into the GPIO pins and report the 0/1 status for triggering the alarm once armed.
I have used cushom.h file with
DIGITAL_PIN
definitions but only got GPIO 14 to show in the status page. Another post says I should useEVENTS_PIN
instead as this will give a real time MQTT response. Either way, my configuration does not give any more than one reading on the status page, just GPIO 14.The text was updated successfully, but these errors were encountered: