wemos I2C mcp23017
Moderators: grovkillen, Stuntteam, TD-er
wemos I2C mcp23017
hello, i am busy on a project which uses an mcp23017 in I2C but when the esp wemos reboot it causes a scan of all the IOs of the mcp23017 changing the pins from Low to High and from High to Low for a brief moment. Is it possible to prevent this? Thank you
Re: wemos I2C mcp23017
What build are you using?
I recently added code to detect an I2C bus freeze.
I wonder if that may have changed this behavior.
Also are you running on ESP32 or ESP8266?
I recently added code to detect an I2C bus freeze.
I wonder if that may have changed this behavior.
Also are you running on ESP32 or ESP8266?
Re: wemos I2C mcp23017
Does it work differently if you change the 'Send boot state' option?
/Ton (PayPal.me)
Re: wemos I2C mcp23017
I'm using wemos and i try later on esp01 (esp8266). Buil version 20111 - Mega. Bud
but in my case I have to work with wemos or nod32 ... esp01 does not have enough input ...
but in my case I have to work with wemos or nod32 ... esp01 does not have enough input ...
Re: wemos I2C mcp23017
"20111" is not really the version of the software. More like the "revision" of the settings file.
Please tell the build file name (shown on the sysinfo page)
The "20111" sounds a bit old to be honest.
Please tell the build file name (shown on the sysinfo page)
The "20111" sounds a bit old to be honest.
Re: wemos I2C mcp23017
I have this firmware ESP_Easy_mega_20201227_normal_ESP8266_1M_VCC ... now i tested with
ESP_Easy_mega_20211005_custom_ESP8266_4M1M
and its the same problem.
i don't quite understand what you mean ... sorry for my basic english
ESP_Easy_mega_20211005_custom_ESP8266_4M1M
and its the same problem.
i don't quite understand what you mean ... sorry for my basic english
Re: wemos I2C mcp23017
Your answers don't clear up what is happening now or if it solves your issue. Can you please explain:
a) What's the difference when you change the 'Send boot state' option?
b) Why are you talking about a Wemos D1 and an ESP01?
/Ton (PayPal.me)
Re: wemos I2C mcp23017
1) no difference when the send boot state is different ...
2) I use wemos with mcp23017 I2c and some I/O (gpio) and rules ... I do not understand why the I / O of the mcp23017 (I2c) changes state during the reset / reboot of the esp. i can't use esp01 because i need 8 gpio. But I will test with esp01 to see if it behaves the same.
2) I use wemos with mcp23017 I2c and some I/O (gpio) and rules ... I do not understand why the I / O of the mcp23017 (I2c) changes state during the reset / reboot of the esp. i can't use esp01 because i need 8 gpio. But I will test with esp01 to see if it behaves the same.
Re: wemos I2C mcp23017
The problem is because the esp processes the values at boot and acts according to the rules! It would therefore be necessary that at boot, it ignores the rules ...
Re: wemos I2C mcp23017
Please post your rules
For example, what do you have to start immediately at boot?
For example, what do you have to start immediately at boot?
Re: wemos I2C mcp23017
Code: Select all
On System#Boot do
monitor,mcp,1,1
monitor,mcp,2,1
monitor,mcp,3,1
monitor,mcp,4,1
monitor,mcp,5,1
monitor,mcp,6,1
monitor,mcp,7,1
monitor,mcp,8,1
monitor,mcp,9,1
monitor,mcp,10,1
monitor,mcp,11,1
monitor,mcp,12,1
monitor,mcp,13,1
monitor,mcp,14,1
monitor,mcp,15,1
monitor,mcp,16,1
endon
on BP1#state do
MCPGPIOTOGGLE,1
endon
on BP2#state do
MCPGPIOTOGGLE,2
endon
on BP3#state do
MCPGPIOTOGGLE,3
endon
on mcp#1 do
Publish,%sysname%/MCP-GPIO/1,[plugin#mcpgpio#pinstate#1]
endon
on mcp#2 do
Publish,%sysname%/MCP-GPIO/2,[plugin#mcpgpio#pinstate#2]
endon
on mcp#3 do
Publish,%sysname%/MCP-GPIO/3,[plugin#mcpgpio#pinstate#3]
endon
- Attachments
-
- Snag_578a399.png (53.46 KiB) Viewed 11781 times
Last edited by TD-er on 15 Oct 2021, 08:16, edited 1 time in total.
Reason: Added code-tags to improve readability
Reason: Added code-tags to improve readability
Re: wemos I2C mcp23017
In your opening post you mention "reboots".
Is that a power cycle or a software reboot (or crash) ?
Is that a power cycle or a software reboot (or crash) ?
Re: wemos I2C mcp23017
More questions:
- Do the Switch configurations for BP1..3 have the option 'Send Boot state' enabled? As that will toggle the MCP ports, per your rules code...
- Why is there no task/device configured for the MCP23017?
- What is the current version of ESPEasy you are using? Did you already upgrade to the latest available release at https://github.com/letscontrolit/ESPEasy/releases ?
- Do the Switch configurations for BP1..3 have the option 'Send Boot state' enabled? As that will toggle the MCP ports, per your rules code...
- Why is there no task/device configured for the MCP23017?
- What is the current version of ESPEasy you are using? Did you already upgrade to the latest available release at https://github.com/letscontrolit/ESPEasy/releases ?
/Ton (PayPal.me)
Re: wemos I2C mcp23017
Hy, thank for your interest
1) send boot states OK (in any case, the problem is the same).
2) I dont understand ...task for the mcpxxx
3) version is the last i think 5 oct 2021 (ESP_Easy_mega_20211005_normal_ESP8266_4M1M)
I think the boot procedure is only active after processing the real boot info! Esp checks the I2C and processes the boot requests afterwards. Do you understand what I mean?
1) send boot states OK (in any case, the problem is the same).
2) I dont understand ...task for the mcpxxx
3) version is the last i think 5 oct 2021 (ESP_Easy_mega_20211005_normal_ESP8266_4M1M)
I think the boot procedure is only active after processing the real boot info! Esp checks the I2C and processes the boot requests afterwards. Do you understand what I mean?
Re: wemos I2C mcp23017
This answer doesn't make it clearer what happens if you turn that option on or off, it would help us to help you if that was stated more clearly.
Well, this thread is about using an MCP23017, but you don't have that device configured, as far as I can see from the screenshots. If we are now talking about another issue, then you should better have started a new thread, to avoid confusion.
If we are still talking about an issue with your setup using that MCP23017, then I would expect it to be configured and enabled, so you can select the desired I2C address.
ESPEasy initializes the I2C bus after boot, when that is configured (by default it is). But it does not initialize any aparatus on that bus, unless it is configured as a Device and enabled. If something funny happens on power-up of an I2C device without that being configured in ESPEasy, then that's the chip to blame, not ESPEasy.
The plugin for MCP23017 does do some initialization, but while I don't fully grasp what it is doing, I expect that it is being initialized correctly, as this plugin is already in the Stable set of plugins for a very long time. If it would have issues, like you have stated in your original post, I would expect that to have been resolved a long time ago.
So, some more testing for you to do:
- Can you disable all Switch plugins and then perform a reboot (either by pressing the reset button or using the Reboot button on the Tools page in the web interface) to see if it still has the behavior you have described?
- Report the exact behavior here please.
/Ton (PayPal.me)
Re: wemos I2C mcp23017
I explain the situation again. The esp is used in toggle mode for the IO mcp23017 ... For this mode I had to create the GPIOs in IN (BP) mode switch push button active low. So the mcp output switches from high to low at each gpio pulse (BP) but if I reboot ... the mcpgpio outputs change states according to the last value of the GPIO State (BP) and that's the whole problem.
1) SEND BOOT STATE : when I activate or not the "send boot state" it does not change anything ... the mcpgpio of the mcp switch state during the reboot. 2) The MCP is configured in the ESP ... No worries, the project works ... GPIOs switch the mcpgio of the mcp23017 to toggle mode. But on reboot, all the mcpgpio switch state.
3) Power OFF ON or boot sequence ... the mcpgpio state change ... i think because the rules ...If I do not create any rules, the mcpgpio will not be modified but obviously the toggle project does not work and I do not know how to act on the mcpgpio via the GPIO
1) SEND BOOT STATE : when I activate or not the "send boot state" it does not change anything ... the mcpgpio of the mcp switch state during the reboot. 2) The MCP is configured in the ESP ... No worries, the project works ... GPIOs switch the mcpgio of the mcp23017 to toggle mode. But on reboot, all the mcpgpio switch state.
3) Power OFF ON or boot sequence ... the mcpgpio state change ... i think because the rules ...If I do not create any rules, the mcpgpio will not be modified but obviously the toggle project does not work and I do not know how to act on the mcpgpio via the GPIO
Re: wemos I2C mcp23017
I'm trying to determine if the pin flipping is caused by your rules or by something else, that's why I asked to disable the Switches BP1..3, as on their state change the MCP pins are toggled. Avoiding that toggle might solve your issue. You can also disable the mcpgpiotoggle commands if you prefer that.
You can also add this command:
to each BPx#state event (incrementing the BP1 to BP2 and BP3 of course) to see what is happening, you can view the log from the Tools/Log page or via serial if that's enabled and connected.
You can also add this command:
Code: Select all
eventlog,'BP1'
/Ton (PayPal.me)
Re: wemos I2C mcp23017
OK, i try ... bud with gpio disabled ... of course the rules dont work.
If the gpio are deactivated, the mcp does not react ... the rules do not receive information and therefore the mcp is not requested
LOG :
126804: SW : GPIO=2 State=0 Output value=0
126819: EVENT: BP1#State=0
126843: ACT : MCPGPIOTOGGLE,1
126847: MCP toggle: port#1: set to 1
126897: EVENT: MCP#1=1
126936: ACT : Publish,ESP_IP188/MCP-GPIO/1,1
126996: Command unknown: MCP-GPIO,1,1
127805: SW : GPIO=2 State=0 Output value=1
127819: EVENT: BP1#State=1
127844: ACT : MCPGPIOTOGGLE,1
127848: MCP toggle: port#1: set to 0
127897: EVENT: MCP#1=0
127938: ACT : Publish,ESP_IP188/MCP-GPIO/1,0
127998: Command unknown: MCP-GPIO,1,0
for the command unknown ... its because jeedom and command i add ...
Thank you for your support.
If the gpio are deactivated, the mcp does not react ... the rules do not receive information and therefore the mcp is not requested
LOG :
126804: SW : GPIO=2 State=0 Output value=0
126819: EVENT: BP1#State=0
126843: ACT : MCPGPIOTOGGLE,1
126847: MCP toggle: port#1: set to 1
126897: EVENT: MCP#1=1
126936: ACT : Publish,ESP_IP188/MCP-GPIO/1,1
126996: Command unknown: MCP-GPIO,1,1
127805: SW : GPIO=2 State=0 Output value=1
127819: EVENT: BP1#State=1
127844: ACT : MCPGPIOTOGGLE,1
127848: MCP toggle: port#1: set to 0
127897: EVENT: MCP#1=0
127938: ACT : Publish,ESP_IP188/MCP-GPIO/1,0
127998: Command unknown: MCP-GPIO,1,0
for the command unknown ... its because jeedom and command i add ...
Thank you for your support.
Last edited by pitchout on 18 Oct 2021, 12:20, edited 1 time in total.
Re: wemos I2C mcp23017
Did you also set up a Controller for your MQTT server? As the publish command seems not to work as intended, it will require such controller to be able to publish anything.
/Ton (PayPal.me)
Re: wemos I2C mcp23017
Yes, the mqtt works ... I use the project with jeedom and the info goes back well.
Re: wemos I2C mcp23017
Hello, no more issue ?
Re: wemos I2C mcp23017
The command you try to give does not have a - in the command.
See: https://espeasy.readthedocs.io/en/lates ... al-mcpgpio
See: https://espeasy.readthedocs.io/en/lates ... al-mcpgpio
Re: wemos I2C mcp23017
Hi,
I created the command "mcp-gpio" My problem isn't that ... it's something else. You have to read the beginning. Thank you.
I created the command "mcp-gpio" My problem isn't that ... it's something else. You have to read the beginning. Thank you.
Re: wemos I2C mcp23017
I looked at the P009 plugin source code and I don't see any explanation to this toggle action (that affects ALL I/O pins) during a warm reboot. However, I did not check the "monitor" command's code to see if it could be related (maybe it's doing this toggle, I don't know).When the esp wemos reboot it causes a scan of all the IOs of the mcp23017 changing the pins from Low to High and from High to Low for a brief moment. Is it possible to prevent this?
Please check again:
1. Are you absolutely sure ALL the MCP23017 I/O pins are toggled during the warm reboot? Warm reboot is a button reset or ESP crash reboot, not a power cycle reset.
2. Does the problem go away if you disable the MCP23017 plugin(s)?
3. Does it go away if you remove all the "monitor" boot rules in the rule file?
From your boot rules ...
Code: Select all
monitor,mcp,1,1
monitor,mcp,2,1
monitor,mcp,3,1
{snip-snip}
I don't use the MCP23017 so I can't help much beyond looking at the code. And for sure, TD-er and Ath are the experts on these things, so please carefully follow any advice they provide.
Edit: My best guess is that the "monitor" command rules are causing the outputs to toggle during boot. That is because I suspect that the Monitor command is reading the pins.
- Thomas
Re: wemos I2C mcp23017
The Monitor command should only read the state of all pins, then apply a mask and determine if a state has changed.
But it could be that the pin mode differs from what is set in the chip and maybe there is the cause of what you're seeing.
Have to check the code for it, but not sure if I can manage to do so in a short time as I am working on other parts of the code and it may take some time to wrap my mind around that code.
But it could be that the pin mode differs from what is set in the chip and maybe there is the cause of what you're seeing.
Have to check the code for it, but not sure if I can manage to do so in a short time as I am working on other parts of the code and it may take some time to wrap my mind around that code.
Re: wemos I2C mcp23017
The only place we can see a mcpgpiotoggle command is in the event handlers for the buttons, so that should be temporarily disabled and re-tested to exclude that this issue is caused by that event or by something else.
/Ton (PayPal.me)
Re: wemos I2C mcp23017
hi, the problem i am having is caused by gpio which is used in toggle mode (in association with "rules"). In the case of a reboot via the espeasy interface or an on off power it is the same. because the rules are active.
If I disable the gpio, then no problem. And the big problem is that with each reboot it reverses the output. So if my outputs are OFF (mcpgpio) ... reboot puts everything ON, and vice versa.
monitor,mcp,X,x
I erased the monitor lines ... I saw that somewhere but I realize thanks to you that they are useless here. Sorry for my lack of knowledge
if I find a possibility of being sure that during a reboot the mcpgpio are in OFF, then it is not very serious. Or that they keep their last state.
Thank you for your patience.
If I disable the gpio, then no problem. And the big problem is that with each reboot it reverses the output. So if my outputs are OFF (mcpgpio) ... reboot puts everything ON, and vice versa.
monitor,mcp,X,x
I erased the monitor lines ... I saw that somewhere but I realize thanks to you that they are useless here. Sorry for my lack of knowledge
if I find a possibility of being sure that during a reboot the mcpgpio are in OFF, then it is not very serious. Or that they keep their last state.
Thank you for your patience.
Re: wemos I2C mcp23017
You can force the state of all pins to a known state at reboot, by simply acting on the system#boot event (see: https://espeasy.readthedocs.io/en/lates ... tem-events )
If you then set the pins to known state, you at least know things will not be running unattended in an unknown state.
If you then set the pins to known state, you at least know things will not be running unattended in an unknown state.
Re: wemos I2C mcp23017
This make me crazy, i'm at the end with this fucking bug ...
why the mcpgpio do not set to 0 ... rules ....
----------------------------------------------------------------------------------
on System#Boot do
monitor,mcp,1,0
monitor,mcp,2,0
monitor,mcp,3,0
monitor,mcp,4,0
monitor,mcp,5,0
monitor,mcp,6,0
monitor,mcp,7,0
monitor,mcp,8,0
monitor,mcp,9,0
monitor,mcp,10,0
monitor,mcp,11,0
monitor,mcp,12,0
monitor,mcp,13,0
monitor,mcp,14,0
monitor,mcp,15,0
monitor,mcp,16,0
endon
on BP1#BP1State do
MCPGPIOtoggle,1
endon
on BP2#BP2State do
MCPGPIOtoggle,2
endon
on BP3#BP3State do
MCPGPIOtoggle,3
endon
on mcp#1 do
Publish,%sysname%/MCP-GPIO/1,[plugin#mcpgpio#pinstate#1]
endon
on mcp#2 do
Publish,%sysname%/MCP-GPIO/2,[plugin#mcpgpio#pinstate#2]
endon
on mcp#3 do
Publish,%sysname%/MCP-GPIO/3,[plugin#mcpgpio#pinstate#3]
endon
on mcp#11 do
Publish,%sysname%/MCP-GPIO/11,[plugin#mcpgpio#pinstate#11]
endon
on mcp#12 do
Publish,%sysname%/MCP-GPIO/12,[plugin#mcpgpio#pinstate#12]
endon
on mcp#13 do
Publish,%sysname%/MCP-GPIO/13,[plugin#mcpgpio#pinstate#13]
endon
on mcp#4 do
Publish,%sysname%/MCP-GPIO/4,[plugin#mcpgpio#pinstate#4]
endon
on mcp#5 do
Publish,%sysname%/MCP-GPIO/5,[plugin#mcpgpio#pinstate#5]
endon
on mcp#6 do
Publish,%sysname%/MCP-GPIO/6,[plugin#mcpgpio#pinstate#6]
endon
eventlog,'BP1'
eventlog,'BP2'
eventlog,'BP3'
mcpgpio,1,0
mcpgpio,2,0
mcpgpio,3,0
mcpgpio,4,0
endon
Re: wemos I2C mcp23017
I think there is a solution, but success depends on the exact requirements of your application.OK but the problem is that the state after reboot must be identical to the last known state ... otherwise the rules will interpret this as a command and play their role
If the goal is to prevent the false triggering of the MCPGPIOTOGGLE rules during reboot, then you can suppress the hardware toggles in your rules. For example:
Code: Select all
on System#Boot do
let,1,0 // Clear Boot Flag.
timerSet,1,30
endon
on Rules#Timer=1 do
let,1,1 // Set Boot Flag
logentry,"Boot Init Period Complete, Enabled MCP Toggles"
endon
On BP1#State do
if [%v1%]=1 // Boot initialization complete, OK to toggle now.
MCPGPIOTOGGLE,1
else
logentry,"BP1 ignored"
endif
endon
On BP2#State do
if [%v1%]=1
MCPGPIOTOGGLE,2
else
logentry,"BP2 ignored"
endif
endon
On BP3#State do
if [%v1%]=1
MCPGPIOTOGGLE,3
else
logentry,"BP3 ignored"
endif
endon
Also, the workaround uses a system timer to manipulate a boot flag. Another method would be to set the flag after WiFi has connected. There are probably other ways to do this to. The intent is to prevent all hardware toggles during a cold or warm reboot.
It's still not clear if/why your BPx#State rules are firing during boot. I don't have a MCP23017 to test, but maybe some other user can investigate this to see if there is a bug in the code. Regardless, use rules to ignore the toggle when a reboot occurs.
- Thomas
Re: wemos I2C mcp23017
This last part of your rules is a bit strange, the 'on mcp#6 do/.../ endon' is fine, but the rest of the code should either be deleted or start with an 'on ... do' line to be of any use. Wouldn't expect it to be executed, but deleting is better if it shouldn't be there.
/Ton (PayPal.me)
Re: wemos I2C mcp23017
To Thomas ...
Thank you for your help
I tried your solution, I get an error
418631: EVENT: BP1#BP1State=0
418651: Calculate: Unknown token
418656: ACT : logentry,'BP1 ignored'
418660: BP1 ignored
421841: DS : Temperature: 44.88 (28-cc-c9-48-08-00-00-f4 [DS18B20])
421962: EVENT: t°#temperature=44.88
422077: WD : Uptime 7 ConnectFailures 0 FreeMem 19024 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
if I continue with this idea it is probably the solution but I am limited in programming knowledge
BUD ... yesterday I found this solution not ideal but which at least puts everything off after a sequence of ON of all outputs
Once again thanks for the help
Thank you for your help
I tried your solution, I get an error
418631: EVENT: BP1#BP1State=0
418651: Calculate: Unknown token
418656: ACT : logentry,'BP1 ignored'
418660: BP1 ignored
421841: DS : Temperature: 44.88 (28-cc-c9-48-08-00-00-f4 [DS18B20])
421962: EVENT: t°#temperature=44.88
422077: WD : Uptime 7 ConnectFailures 0 FreeMem 19024 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
if I continue with this idea it is probably the solution but I am limited in programming knowledge
BUD ... yesterday I found this solution not ideal but which at least puts everything off after a sequence of ON of all outputs
Code: Select all
on System#Boot do
monitor,mcp,1
monitor,mcp,2
monitor,mcp,3
monitor,mcp,4
monitor,mcp,5
monitor,mcp,6
monitor,mcp,7
monitor,mcp,8
monitor,mcp,9
monitor,mcp,10
monitor,mcp,11
monitor,mcp,12
monitor,mcp,13
monitor,mcp,14
monitor,mcp,15
monitor,mcp,16
endon
on System#Boot do
timerSet,1,5 //Set Timer 1 for the next event in 10 seconds
endon
On Rules#Timer=1 do //When Timer1 expires, do
mcpgpioRange,1,16,0
endon
on BP1#BP1State do
MCPGPIOtoggle,1
endon
on BP2#BP2State do
MCPGPIOtoggle,2
endon
on BP3#BP3State do
MCPGPIOtoggle,3
endon
on BP4#BP4State do
MCPGPIOtoggle,4
endon
on BP5#BP5State do
MCPGPIOtoggle,5
endon
on BP6#BP6State do
MCPGPIOtoggle,6
endon
on mcp#1 do
Publish,%sysname%/MCP-GPIO/1,[plugin#mcpgpio#pinstate#1]
endon
on mcp#2 do
Publish,%sysname%/MCP-GPIO/2,[plugin#mcpgpio#pinstate#2]
endon
on mcp#3 do
Publish,%sysname%/MCP-GPIO/3,[plugin#mcpgpio#pinstate#3]
endon
on mcp#11 do
Publish,%sysname%/MCP-GPIO/11,[plugin#mcpgpio#pinstate#11]
endon
on mcp#12 do
Publish,%sysname%/MCP-GPIO/12,[plugin#mcpgpio#pinstate#12]
endon
on mcp#13 do
Publish,%sysname%/MCP-GPIO/13,[plugin#mcpgpio#pinstate#13]
endon
on mcp#4 do
Publish,%sysname%/MCP-GPIO/4,[plugin#mcpgpio#pinstate#4]
endon
on mcp#5 do
Publish,%sysname%/MCP-GPIO/5,[plugin#mcpgpio#pinstate#5]
endon
on mcp#6 do
Publish,%sysname%/MCP-GPIO/6,[plugin#mcpgpio#pinstate#6]
endon
eventlog,'BP1'
eventlog,'BP2'
eventlog,'BP3'
on System#Wake do
mcpgpioRange,1,16,0
endon
Last edited by TD-er on 23 Oct 2021, 22:03, edited 1 time in total.
Reason: Wrapped the rules in [code] tags
Reason: Wrapped the rules in [code] tags
Re: wemos I2C mcp23017
I tried your solution, I get an error
Code: Select all
418631: EVENT: BP1#BP1State=0
418651: Calculate: Unknown token
418656: ACT : logentry,'BP1 ignored'
418660: BP1 ignored
421841: DS : Temperature: 44.88 (28-cc-c9-48-08-00-00-f4 [DS18B20])
421962: EVENT: t°#temperature=44.88
422077: WD : Uptime 7 ConnectFailures 0 FreeMem 19024 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
But I did find a mistake in my examples. All the lines that look like this:
Code: Select all
if [%v1%]=1
Code: Select all
if %v1%=1
Code: Select all
on System#Boot do
mcpgpioRange,1,16,0 // Copied from System#Wake rule
let,1,0 // Clear Boot Flag
timerSet,1,30 // Boot Flag Timer
endon
Code: Select all
eventlog,'BP1'
eventlog,'BP2'
eventlog,'BP3'
If they fit, I suggest moving ALL your rules to a single rule page. Starting with the "Rules Set 1" page. I mention this because you posted a screenshot of your Rules Set 2 page, which suggests that you are using two pages for your rules. I find that a single page is easier to debug and will often execute faster.
As a courtesy please wrap your posted rules in code brackets. This requires using the forum's "</>" formatting button. When source text is posted without code display formatting it is harder for developers to digest. And in a worse case, unformatted source text may cause the code reviewer's eyes to bleed.
- Thomas
Re: wemos I2C mcp23017
I added the code tags on the rules in his post to improve readability.
Re: wemos I2C mcp23017
To start over on a good basis, here is my code rules on one page ...
I think I corrected the old code, but can you confirm it is correct? That said, it still doesn't work. The MCP outputs go well to 0 ... but I have again a sequence towards state 1 of all the outputs afterwards.
Thanks a lot.
Code: Select all
on System#Boot do
mcpgpioRange,1,16,0 // Copied from System#Wake rule
let,1,0 // Clear Boot Flag
timerSet,1,30 // Boot Flag Timer
endon
on System#Boot do
let,1,0 // Clear Boot Flag.
timerSet,1,30
endon
on Rules#Timer=1 do
let,1,1 // Set Boot Flag
logentry,"Boot Init Period Complete, Enabled MCP Toggles"
endon
On BP1#BP1State do
if %v1%=1 // Boot initialization complete, OK to toggle now.
MCPGPIOTOGGLE,1
else
logentry,"BP1 ignored"
endif
endon
On BP2#BP2State do
if %v1%=1
MCPGPIOTOGGLE,2
else
logentry,"BP2 ignored"
endif
endon
On BP3#BP3State do
if %v1%=1
MCPGPIOTOGGLE,3
else
logentry,"BP3 ignored"
endif
endon
monitor,mcp,1
monitor,mcp,2
monitor,mcp,3
monitor,mcp,4
monitor,mcp,5
monitor,mcp,6
monitor,mcp,7
monitor,mcp,8
monitor,mcp,9
monitor,mcp,10
monitor,mcp,11
monitor,mcp,12
monitor,mcp,13
monitor,mcp,14
monitor,mcp,15
monitor,mcp,16
endon
on BP1#BP1State do
MCPGPIOtoggle,1
endon
on BP2#BP2State do
MCPGPIOtoggle,2
endon
on BP3#BP3State do
MCPGPIOtoggle,3
endon
on BP4#BP4State do
MCPGPIOtoggle,4
endon
on BP5#BP5State do
MCPGPIOtoggle,5
endon
on BP6#BP6State do
MCPGPIOtoggle,6
endon
on mcp#1 do
Publish,%sysname%/MCP-GPIO/1,[plugin#mcpgpio#pinstate#1]
endon
on mcp#2 do
Publish,%sysname%/MCP-GPIO/2,[plugin#mcpgpio#pinstate#2]
endon
on mcp#3 do
Publish,%sysname%/MCP-GPIO/3,[plugin#mcpgpio#pinstate#3]
endon
on mcp#11 do
Publish,%sysname%/MCP-GPIO/11,[plugin#mcpgpio#pinstate#11]
endon
on mcp#12 do
Publish,%sysname%/MCP-GPIO/12,[plugin#mcpgpio#pinstate#12]
endon
on mcp#13 do
Publish,%sysname%/MCP-GPIO/13,[plugin#mcpgpio#pinstate#13]
endon
on mcp#4 do
Publish,%sysname%/MCP-GPIO/4,[plugin#mcpgpio#pinstate#4]
endon
on mcp#5 do
Publish,%sysname%/MCP-GPIO/5,[plugin#mcpgpio#pinstate#5]
endon
on mcp#6 do
Publish,%sysname%/MCP-GPIO/6,[plugin#mcpgpio#pinstate#6]
endon
Thanks a lot.
Re: wemos I2C mcp23017
I'll do my best to help resolve the unwanted toggles at boot. After that, you can proceed to further revise the rule logic to do the things your device needs to do.
At this point there are issues in your rule file (duplicate events, incomplete code, etc.). I can help with that. But some details of your project are unclear to me.
For instance, I see that you are using MCP23017 I/O pins 1-6 as switch inputs. But these same pins are used as outputs. What are you trying to do here? If you really intended to do this, then I advise that the output pins be assigned to other (unused) pins on the MCP23017. That is to say, separate the push button switch inputs from the toggled output signals.
I assume you have momentary pushbutton switches connected to the input pins. But what is connected to the output pins / what is their function?
In case it helps your understanding of rule creation/formatting, here's your rule file (untested) after removing the errors I saw.
I don't use the MCP23017, so my edits are untested. Hopefully the "boot" toggle problem is resolved after you apply the revised rule set. But even so, I suspect you have more work to do; So plan on revising the rules to achieve the intended device operation.
If the file becomes too large to fit on a single ESPEasy rule page then feel free to remove the logentry statements. Those are for debugging the code (via log) and are not required for normal operation.
- Thomas
At this point there are issues in your rule file (duplicate events, incomplete code, etc.). I can help with that. But some details of your project are unclear to me.
For instance, I see that you are using MCP23017 I/O pins 1-6 as switch inputs. But these same pins are used as outputs. What are you trying to do here? If you really intended to do this, then I advise that the output pins be assigned to other (unused) pins on the MCP23017. That is to say, separate the push button switch inputs from the toggled output signals.
I assume you have momentary pushbutton switches connected to the input pins. But what is connected to the output pins / what is their function?
In case it helps your understanding of rule creation/formatting, here's your rule file (untested) after removing the errors I saw.
Code: Select all
on System#Boot do
monitor,mcp,1,1 // Monitor MCP23017 INPUT pins.
monitor,mcp,2,1
monitor,mcp,3,1
monitor,mcp,4,1
monitor,mcp,5,1
monitor,mcp,6,1
mcpgpioRange,1,16,0 // All MCP Outputs low.
let,1,0 // Clear Boot Flag
timerSet,1,30 // Boot Flag Timer
endon
on Rules#Timer=1 do
let,1,1 // Set Boot Flag
logentry,"Boot Timer Expired, Enabled MCP Toggles"
endon
On BP1#BP1State do
if %v1%=1
MCPGPIOTOGGLE,1
logentry,"BP1 Toggled"
else
logentry,"BP1 Toggle ignored"
endif
endon
On BP2#BP2State do
if %v1%=1
MCPGPIOTOGGLE,2
logentry,"BP2 Toggled"
else
logentry,"BP2 Toggle ignored"
endif
endon
On BP3#BP3State do
if %v1%=1
MCPGPIOTOGGLE,3
logentry,"BP3 Toggled"
else
logentry,"BP3 Toggle ignored"
endif
endon
on BP4#BP4State do
if %v1%=1
MCPGPIOtoggle,4
logentry,"BP4 Toggled"
else
logentry,"BP4 Toggle ignored"
endif
endon
on BP5#BP5State do
if %v1%=1
MCPGPIOtoggle,5
logentry,"BP5 Toggled"
else
logentry,"BP5 Toggle ignored"
endif
endon
on BP6#BP6State do
if %v1%=1
MCPGPIOtoggle,6
logentry,"BP6 Toggled"
else
logentry,"BP6 Toggle ignored"
endif
endon
on mcp#1 do
Publish,%sysname%/MCP-GPIO/1,[plugin#mcpgpio#pinstate#1]
endon
on mcp#2 do
Publish,%sysname%/MCP-GPIO/2,[plugin#mcpgpio#pinstate#2]
endon
on mcp#3 do
Publish,%sysname%/MCP-GPIO/3,[plugin#mcpgpio#pinstate#3]
endon
on mcp#4 do
Publish,%sysname%/MCP-GPIO/4,[plugin#mcpgpio#pinstate#4]
endon
on mcp#5 do
Publish,%sysname%/MCP-GPIO/5,[plugin#mcpgpio#pinstate#5]
endon
on mcp#6 do
Publish,%sysname%/MCP-GPIO/6,[plugin#mcpgpio#pinstate#6]
endon
on mcp#11 do
Publish,%sysname%/MCP-GPIO/11,[plugin#mcpgpio#pinstate#11]
endon
on mcp#12 do
Publish,%sysname%/MCP-GPIO/12,[plugin#mcpgpio#pinstate#12]
endon
on mcp#13 do
Publish,%sysname%/MCP-GPIO/13,[plugin#mcpgpio#pinstate#13]
endon
If the file becomes too large to fit on a single ESPEasy rule page then feel free to remove the logentry statements. Those are for debugging the code (via log) and are not required for normal operation.
- Thomas
Re: wemos I2C mcp23017
Hello, to answer you for the use and the function of this assembly. It is ... via 8 switch IN (gpio wemos) to act on 8 outputs (I2C MCP23017) by creating rules to obtain the toggle function. BUT the most important thing was to be able to integrate it into my JEEDOM home automation system and therefore have feedback on the state of the outputs via MQTT. Hence also the need for "monitor, mcp, x, x"
It seems that your help has paid off The circuit is reacting well. All the outputs switch to OFF and remain so until an intervention of the Switch or jeedom. A big thank you, you are my idol for a couple of weeks ...
If I encounter an anomaly, I will come back to the forum.
Jeedom : jeedom and MCP23017
It seems that your help has paid off The circuit is reacting well. All the outputs switch to OFF and remain so until an intervention of the Switch or jeedom. A big thank you, you are my idol for a couple of weeks ...
If I encounter an anomaly, I will come back to the forum.
Jeedom : jeedom and MCP23017
Re: wemos I2C mcp23017
You are welcome. Glad to hear you got it working.
- Thomas
- Thomas
Who is online
Users browsing this forum: No registered users and 3 guests