GPIO pin state monitoring
Moderators: grovkillen, Stuntteam, TD-er
GPIO pin state monitoring
I have a Relay connected to GPIO5 (so Im using GPIO5 as an output)
I turn it on/off using command GPIO,5,1/0 over MQTT
Rather than assume that the MQTT message has been received and actioned, I'd also like the to read the status of GPIO5 and have it reported back over MQTT
but I cant find a way to make work.
I'm new to rules but I can create a rule which monitors the status of a input switch device on the pin(5) but not if the pin state has been changed by a command
Any pointers gratefully received.
Thanks
PS Sorry if this is covered elsewhere but I cant find my answer in here or in wiki.
I turn it on/off using command GPIO,5,1/0 over MQTT
Rather than assume that the MQTT message has been received and actioned, I'd also like the to read the status of GPIO5 and have it reported back over MQTT
but I cant find a way to make work.
I'm new to rules but I can create a rule which monitors the status of a input switch device on the pin(5) but not if the pin state has been changed by a command
Any pointers gratefully received.
Thanks
PS Sorry if this is covered elsewhere but I cant find my answer in here or in wiki.
Re: GPIO pin state monitoring
The "monitor" command should handle this as it is polling the monitored pins multiple times a second.
In this (pending) pull request there is also some long overdue documentation for the GPIO commands: https://github.com/letscontrolit/ESPEasy/pull/3431
In this (pending) pull request there is also some long overdue documentation for the GPIO commands: https://github.com/letscontrolit/ESPEasy/pull/3431
Re: GPIO pin state monitoring
TD-er
Thanks, I'll take a look tomorrow.
I had been using monitor but perhaps incorrectly.
Update:
Dont know what I was doing wrong yesterday but today "monitor" works just fine for me.
Sorry to waste your time
Rules attached for the benefit of other Rules newbies like me.
Thanks, I'll take a look tomorrow.
I had been using monitor but perhaps incorrectly.
Update:
Dont know what I was doing wrong yesterday but today "monitor" works just fine for me.
Sorry to waste your time
Rules attached for the benefit of other Rules newbies like me.
Code: Select all
on System#Boot do
Monitor gpio,4
Monitor gpio,5
Monitor gpio,15
endon
On gpio#4=1 do
Publish,MYESP/electrical.chargers.thruster,ON
endon
On gpio#4=0 do
Publish,MYESP/electrical.chargers.thruster,OFF
endon
On gpio#5=1 do
Publish,MYESP/electrical.chargers.start,ON
endon
on gpio#5=0 do
Publish,MYESP/electrical.chargers.start,OFF
endon
On gpio#13=1 do
Publish,MYESP/electrical.chargers.solar,ON
endon
On gpio#13=0 do
Publish,MYESP/electrical.chargers.solar,OFF
endon
Re: GPIO pin state monitoring
a workaround is to set avariable each time a gpio changes
then you can check or send it out with
if [VAR#4]=1
or publish .... [VAR#4]
Code: Select all
On gpio#4=1 do
Publish,MYESP/electrical.chargers.thruster,ON
let,4,1
endon
if [VAR#4]=1
or publish .... [VAR#4]
Re: GPIO pin state monitoring
The good old method still works:
( ESP_Easy_mega_20201227_minimal_core_274_ESP8285_1M_OTA_Domoticz )
code example from my code for relay toggle ( and report actual state to Domoticz ):
( ESP_Easy_mega_20201227_minimal_core_274_ESP8285_1M_OTA_Domoticz )
code example from my code for relay toggle ( and report actual state to Domoticz ):
Code: Select all
on change do
if [Relay#State]=0
gpio,12,1
SendToHTTP 192.168.1.253,8080,/json.htm?type=command¶m=switchlight&idx=163&switchcmd=On
else
gpio,12,0
SendToHTTP 192.168.1.253,8080,/json.htm?type=command¶m=switchlight&idx=163&switchcmd=Off
endif
endon
Re: GPIO pin state monitoring
question regarding monitoring GPIO.
When monitored it is checking the status several times a second.
does this also mean that when you have someting like
On GPIO#12=0 do
this is also called serveral times a second or only once it changes from 1 to 0
if it does this means monitoring GPIO increases the workload a lot
When monitored it is checking the status several times a second.
does this also mean that when you have someting like
On GPIO#12=0 do
this is also called serveral times a second or only once it changes from 1 to 0
if it does this means monitoring GPIO increases the workload a lot
Re: GPIO pin state monitoring
Yep, the monitoring is potentially a real resource hog.
I am not really sure yet what to do to help this out a bit as it does fire an event, which gets processed in the rules.
Rules processing is already taking quite a hit on performance if done at a higher rate.
See also https://espeasy.readthedocs.io/en/lates ... tem-events
I can give a few tips to make rules processing less of an issue.
- Place the most frequently called events on top of the first rules file
- Try matching on %eventvalueN% in the event handler block and not too specific on...do specifiers.
I am not really sure yet what to do to help this out a bit as it does fire an event, which gets processed in the rules.
Rules processing is already taking quite a hit on performance if done at a higher rate.
See also https://espeasy.readthedocs.io/en/lates ... tem-events
Code: Select all
on System#Boot do
Monitor GPIO,15
endon
on GPIO#15=0 do
if [Plugin#GPIO#Pinstate#13]=0
// do something
endif
endon
on GPIO#15=1 do
if [Plugin#GPIO#Pinstate#13]=1
// do something
endif
endon
- Place the most frequently called events on top of the first rules file
- Try matching on %eventvalueN% in the event handler block and not too specific on...do specifiers.
Re: GPIO pin state monitoring
thanks.
good to know that this is causin extra load which can be avoided
normally i use the eventhandler but for testing purposes i use GPIO monitoring.
When i am done testing i will switch back
good to know that this is causin extra load which can be avoided
normally i use the eventhandler but for testing purposes i use GPIO monitoring.
When i am done testing i will switch back
Who is online
Users browsing this forum: No registered users and 67 guests