wemos I2C mcp23017

Moderators: grovkillen, Stuntteam, TD-er

Post Reply
Message
Author
pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

wemos I2C mcp23017

#1 Post by pitchout » 13 Oct 2021, 20:00

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

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: wemos I2C mcp23017

#2 Post by TD-er » 13 Oct 2021, 21:43

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?

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: wemos I2C mcp23017

#3 Post by Ath » 13 Oct 2021, 21:43

Does it work differently if you change the 'Send boot state' option?
/Ton (PayPal.me)

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#4 Post by pitchout » 14 Oct 2021, 17:10

Yes ... :-(

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#5 Post by pitchout » 14 Oct 2021, 17:11

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 ...

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: wemos I2C mcp23017

#6 Post by TD-er » 14 Oct 2021, 18:59

"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.

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#7 Post by pitchout » 14 Oct 2021, 19:24

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

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: wemos I2C mcp23017

#8 Post by Ath » 14 Oct 2021, 20:08

Ath wrote: 13 Oct 2021, 21:43 Does it work differently if you change the 'Send boot state' option?
pitchout wrote: 14 Oct 2021, 17:10Yes ... :-(
pitchout wrote: 14 Oct 2021, 17:11 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 ...
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)

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#9 Post by pitchout » 14 Oct 2021, 20:56

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.

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#10 Post by pitchout » 14 Oct 2021, 21:09

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 ...

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: wemos I2C mcp23017

#11 Post by TD-er » 14 Oct 2021, 21:17

Please post your rules

For example, what do you have to start immediately at boot?

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#12 Post by pitchout » 15 Oct 2021, 06:26

Image

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
Snag_578a399.png (53.46 KiB) Viewed 10953 times
Last edited by TD-er on 15 Oct 2021, 08:16, edited 1 time in total.
Reason: Added code-tags to improve readability

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: wemos I2C mcp23017

#13 Post by TD-er » 15 Oct 2021, 08:31

In your opening post you mention "reboots".
Is that a power cycle or a software reboot (or crash) ?

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: wemos I2C mcp23017

#14 Post by Ath » 15 Oct 2021, 08:45

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 ?
/Ton (PayPal.me)

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#15 Post by pitchout » 16 Oct 2021, 09:34

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?

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: wemos I2C mcp23017

#16 Post by Ath » 16 Oct 2021, 16:43

pitchout wrote: 16 Oct 2021, 09:34 1) send boot states OK (in any case, the problem is the same).
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.
pitchout wrote: 16 Oct 2021, 09:34 2) I dont understand ...task for the mcpxxx
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.
pitchout wrote: 16 Oct 2021, 09:34 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?
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)

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#17 Post by pitchout » 16 Oct 2021, 19:32

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.
Snag_d7add34.png
Snag_d7add34.png (37.57 KiB) Viewed 10831 times
Snag_d7b73e6.png
Snag_d7b73e6.png (46.57 KiB) Viewed 10831 times
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

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: wemos I2C mcp23017

#18 Post by Ath » 16 Oct 2021, 20:29

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:

Code: Select all

eventlog,'BP1'
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.
/Ton (PayPal.me)

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#19 Post by pitchout » 16 Oct 2021, 22:49

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.
Last edited by pitchout on 18 Oct 2021, 12:20, edited 1 time in total.

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: wemos I2C mcp23017

#20 Post by Ath » 16 Oct 2021, 23:18

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)

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#21 Post by pitchout » 17 Oct 2021, 11:13

Yes, the mqtt works ... I use the project with jeedom and the info goes back well.

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#22 Post by pitchout » 20 Oct 2021, 08:12

Hello, no more issue ?

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: wemos I2C mcp23017

#23 Post by TD-er » 20 Oct 2021, 09:58

The command you try to give does not have a - in the command.
See: https://espeasy.readthedocs.io/en/lates ... al-mcpgpio

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#24 Post by pitchout » 20 Oct 2021, 20:32

Hi,

I created the command "mcp-gpio" My problem isn't that ... it's something else. You have to read the beginning. Thank you.

User avatar
ThomasB
Normal user
Posts: 1064
Joined: 17 Jun 2018, 20:41
Location: USA

Re: wemos I2C mcp23017

#25 Post by ThomasB » 20 Oct 2021, 21:16

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?
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).

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 recognize this exact parameter usage. What does the last parameter ("1") at the end of each line do?

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

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: wemos I2C mcp23017

#26 Post by TD-er » 20 Oct 2021, 23:47

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.

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: wemos I2C mcp23017

#27 Post by Ath » 21 Oct 2021, 09:23

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)

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#28 Post by pitchout » 21 Oct 2021, 22:44

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.

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: wemos I2C mcp23017

#29 Post by TD-er » 21 Oct 2021, 23:22

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.

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#30 Post by pitchout » 22 Oct 2021, 17:27

Snag_aa544f2.png
Snag_aa544f2.png (22.27 KiB) Viewed 10489 times
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

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

User avatar
ThomasB
Normal user
Posts: 1064
Joined: 17 Jun 2018, 20:41
Location: USA

Re: wemos I2C mcp23017

#31 Post by ThomasB » 22 Oct 2021, 21:15

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
I think there is a solution, but success depends on the exact requirements of your application.

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
The above is an untested rule example. And it is missing some of your other rules. So test and revise it as required for your application.

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

User avatar
Ath
Normal user
Posts: 3418
Joined: 10 Jun 2018, 12:06
Location: NL

Re: wemos I2C mcp23017

#32 Post by Ath » 22 Oct 2021, 21:28

pitchout wrote: 22 Oct 2021, 17:27 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
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)

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#33 Post by pitchout » 23 Oct 2021, 09:20

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

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
Once again thanks for the help
Last edited by TD-er on 23 Oct 2021, 22:03, edited 1 time in total.
Reason: Wrapped the rules in [code] tags

User avatar
ThomasB
Normal user
Posts: 1064
Joined: 17 Jun 2018, 20:41
Location: USA

Re: wemos I2C mcp23017

#34 Post by ThomasB » 23 Oct 2021, 20:22

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
You didn't post your rule file, so I don't know the reason for the Calculate: Unknown token error. That usually means there is an arithmetic problem, usually related to an uninitialized variable.

But I did find a mistake in my examples. All the lines that look like this:

Code: Select all

if [%v1%]=1
should be changed to:

Code: Select all

if %v1%=1
Also, I will assume that you are not using the ESPEasy's sleep feature. So I suggest removing the System#Wake event rule and move its code to the System#Boot event. For example:

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
And as Ath has mentioned before, there's some random code in your rule file that needs to be removed. Specifically these text lines in your previous listing:

Code: Select all

eventlog,'BP1'
eventlog,'BP2'
eventlog,'BP3'
Some Personal tips:

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

TD-er
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: wemos I2C mcp23017

#35 Post by TD-er » 23 Oct 2021, 22:04

I added the code tags on the rules in his post to improve readability.

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#36 Post by pitchout » 26 Oct 2021, 18:18

To start over on a good basis, here is my code rules on one page ...

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

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.

User avatar
ThomasB
Normal user
Posts: 1064
Joined: 17 Jun 2018, 20:41
Location: USA

Re: wemos I2C mcp23017

#37 Post by ThomasB » 26 Oct 2021, 20:44

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.

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
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

pitchout
Normal user
Posts: 34
Joined: 13 Oct 2021, 19:57

Re: wemos I2C mcp23017

#38 Post by pitchout » 27 Oct 2021, 19:52

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 mcp.png
jeedom mcp.png (57.7 KiB) Viewed 10094 times
jeedom and MCP23017
jeedom.png
jeedom.png (510.14 KiB) Viewed 10094 times

User avatar
ThomasB
Normal user
Posts: 1064
Joined: 17 Jun 2018, 20:41
Location: USA

Re: wemos I2C mcp23017

#39 Post by ThomasB » 27 Oct 2021, 20:49

You are welcome. Glad to hear you got it working.

- Thomas

Post Reply

Who is online

Users browsing this forum: No registered users and 29 guests