ESPEasy 🚀 - PCF8574 Keypad plugin behavior questions.

Yes, it is possible to mark pins to trigger an interrupt.
However, that has some impact on the iRAM (cache) memory usage.
And it will also interrupt (pun intended) other tasks, which may lead to crashing plugins because such behavior was never tested.

If you want to see an example in code to how to set an interrupt to a pin, see this pull request of my attempt to reduce cache (iRAM) usage of the software serial port: #631
See this file: https://github.com/letscontrolit/ESPEasy/pull/631/files#diff-e1c00b8efaa00fbd65a0d47afeb3948d

TD-er on 13 Dec 2017

I don't have any code skills at all. ESPEasy rules are about as complicated as I will ever begin to understand. :)

Budman1758 on 13 Dec 2017

I was just looking into the chip you used. (stated in the subject line)
Is this chip perhaps a better choice? http://www.ti.com/lit/ds/symlink/tca8418e.pdf
That one also has a buffer to store entered keypresses and it could be read several times a second.
Not sure if it is supported, but that should not be too hard, judging the datasheet.

TD-er on 13 Dec 2017

That looks a bit more like something made for the task. Reason I'm using the PCF8574 is cause its already in the firmware. Feel like writing a plugin? I'll buy the chips n salsa.

Budman1758 on 13 Dec 2017

Looking at the datasheet now it would be pretty difficult to work with that particular package on a breadboard.

Budman1758 on 13 Dec 2017

Indeed, Ball-grid-arrays are not very useful on a breadboard :)

It was the first hit when looking for some kind of I2C keyboard controller.
The thing is that it sounds like a bad idea to poll key strokes on a matrix at such a slow interval.
There are controllers to do the real-time job and then let the ESP just do the interpretation and communications.

I just saw this setup (in Dutch) with an Arduino and the chip + keypad you already have: http://demo.jezietheternietaanaf.nl/keypad-aansluiten-via-i2c/
Perhaps you have also an Arduino laying around, just to test how responsive it can be. The ESP however isn't that responsive, because lots of other tasks have to be performed.

It might be possible to run such a plugin at a faster interval, but still it may not be as fast as the Arduino solution which doesn't have to do anything else. And I don't know what effect it may have on the rest of the operations.

I will try to order these parts, so in a month or so, when the parts arrived, I may have a look at the plugin :)

TD-er on 13 Dec 2017

You can use small arduino nano directly connected to keypad to scan and
send keycode, and espeasy connected to this nano board by rs232 or mimic
one of these i2c chip.

13.12.2017 9:20 AM "Gijs Noorlander" notifications@github.com napisał(a):

Indeed, Ball-grid-arrays are not very useful on a breadboard :)

It was the first hit when looking for some kind of I2C keyboard controller.
The thing is that it sounds like a bad idea to poll key strokes on a
matrix at such a slow interval.
There are controllers to do the real-time job and then let the ESP just do
the interpretation and communications.

I just saw this setup (in Dutch) with an Arduino and the chip + keypad you
already have: http://demo.jezietheternietaanaf.nl/
keypad-aansluiten-via-i2c/
Perhaps you have also an Arduino laying around, just to test how
responsive it can be. The ESP however isn't that responsive, because lots
of other tasks have to be performed.

It might be possible to run such a plugin at a faster interval, but still
it may not be as fast as the Arduino solution which doesn't have to do
anything else. And I don't know what effect it may have on the rest of the
operations.

I will try to order these parts, so in a month or so, when the parts
arrived, I may have a look at the plugin :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-351317215,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOU3Yt1AvyAn3ZpE-_A2-wVzw_fxZcks5s_4jRgaJpZM4Q_wVN
.

uzi18 on 13 Dec 2017

I understand there are all kinds of other ways to do this but it kinda takes a lot of the "easy" out of ESPEasy. I am not a programmer at all. I just bash stuff together and ESPEasy takes the programming pretty much out of the equation for people like me.

Not trying to be an ass here but keypad "support" would seem to indicate you can actually use it as such. Having to wait several seconds between keypresses doesn't really add up to "support" IMHO. I understand its in testing phase too. Do the other keypad chips supported work the same with ESPEasy?

Budman1758 on 13 Dec 2017

Like I said, I will order the parts myself and see what can be changed.
Only thing is, it probably won't be fixed before the 2.0.0 release, which is almost completed and I think I am already driving @psy0rz and @Grovkillen close to madness with all the pull-requests to be merged :)

I totally agree that entering keys like you describe is not how it should be.
Let's hope it can be fixed in software, but I expect proper key-press detection can only be done by sampling the keypad several tens of times a second and I am not really sure the combination of ESPeasy and that chip are up for that task.
But time will tell :)

TD-er on 13 Dec 2017

😄1

@TD-er @Grovkillen : do we have any info how long does it take to get scancode?

uzi18 on 13 Dec 2017

@uzi18 I just browsed through the datasheet and at first glance there is not much to say about the maximum sample rate.

But, I just saw this:

The PCF8574 device provides an open-drain output (INT) that can be connected to the interrupt input of a microcontroller. An interrupt is generated by any rising or falling edge of the port inputs in the input mode.

This means, it is possible to connect the INT line to the controller to trigger a read.
So you have to set 4 rows to high and when any of the input lines change (by a keypress) the INT line will trigger.
Then you have to disable the trigger and perform up to 4 samples to detect which key was pressed. Each sample consists of setting 1 output line and a read.
So I guess you have to perform about 8 read/write actions.
Each of 3(??) bytes. So that's 8*24 bit + some delay between commands. With 100kHz I2C is that less than 500 times per seconds. How much less depends on the minimum delay between writing and reading.
And often keypresses are not immediate, but bounce. So perhaps you'll have to scan for a few tens of milliseconds.

If no other devices trigger interrupts and no other I2C devices are active and no processing time is spent on other tasks like the WiFi, then it should be possible to detect the key presses accurately. But if those other interrupts are present during a keypress, the moment to scan which key was pressed may be too short to detect properly.

TD-er on 13 Dec 2017

I mean if scancode takes too long we can scan one line every 20ms
80ms is not too long and with debounce 160 is enough.

13.12.2017 9:11 PM "Gijs Noorlander" notifications@github.com napisał(a):

@uzi18 https://github.com/uzi18 I just browsed through the datasheet and
at first glance there is not much to say about the maximum sample rate.

But, I just saw this:

The PCF8574 device provides an open-drain output (INT) that can be
connected to the interrupt input of a microcontroller. An interrupt is
generated by any rising or falling edge of the port inputs in the input
mode.

This means, it is possible to connect the INT line to the controller to
trigger a read.
So you have to set 4 rows to high and when any of the input lines change
(by a keypress) the INT line will trigger.
Then you have to disable the trigger and perform up to 4 samples to detect
which key was pressed. Each sample consists of setting 1 output line and a
read.
So I guess you have to perform about 8 read/write actions.
Each of 3(??) bytes. So that's 8*24 bit + some delay between commands. With
100kHz I2C is that less than 500 times per seconds. How much less depends
on the minimum delay between writing and reading.
And often keypresses are not immediate, but bounce. So perhaps you'll have
to scan for a few tens of milliseconds.

If no other devices trigger interrupts and no other I2C devices are active
and no processing time is spent on other tasks like the WiFi, then it
should be possible to detect the key presses accurately. But if those other
interrupts are present during a keypress, the moment to scan which key was
pressed may be too short to detect properly.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-351508138,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOUyMV-lO9DW7NkRwOxXO262r9EwiGks5tAC9wgaJpZM4Q_wVN
.

uzi18 on 13 Dec 2017

I was just thinking, you can determine the scancode in 2 samples.

preparation: Set the rows active as high output + activate the INT mode

INT triggers interrupt => Read inputs.
Then you know which column is active.

Next: Set that column as output and the row lines as input and set the output high.
Then read the inputs and there should be 1 row active.
Repeat this a number of times to prevent false detection by bouncing keys.

I think the problem is not in scanning every N msec. The problem is more that there is not much of a guarantee it can be done within N msec after the INT line is triggered.
And then keypresses are easy to miss.

TD-er on 13 Dec 2017

50ms is ok for debouncing
I'm thinking about 4 samples - every row * 20ms.
Tu be sure what is going on we need to measure time to go into scan code and scanning time.
So we will know exactly how long scanning takes and how often it is launched.

uzi18 on 13 Dec 2017

Problem is I still have to order the parts to be able to test :)

TD-er on 13 Dec 2017

You can use i2c->lcd (usualy pcf8574 based) converter and connect keypad to it or just shortcut pins there :)

uzi18 on 13 Dec 2017

The thing I see in the serial output is that the keypress itself is not "seen" by ESPEasy when it is doing ANY other processing. Is there a way to "pause" the processor until the code is done being entered? Perhaps a # key followed by whatever code and then a * to tell the processor to resume? In other words # tells the processor to listen up and * says OK run with it? Or maybe make use of the timers function in the rules engine? Just throwing stuff out there to see if anything sticks. :)

Budman1758 on 13 Dec 2017

I just looked at the P61 keypad plugin.
It looks like the INT line is not being used in the plugin.
I guess it can only work properly if either the keypad is scanned continuously (won't happen on the ESP8266) or when an interrupt is triggered.
So to get it to work properly, the INT line should be connected to a GPIO pin of the ESP and that pin should be set to call a function when triggered.
That function should be the reading of a single key stroke and re-enabling the INT line.

TD-er on 13 Dec 2017

That sounds like something that needs to be a part of the plugin.

Budman1758 on 14 Dec 2017

Indeed, I guess it would help a lot.

TD-er on 14 Dec 2017

@TD-er Your work is much appreciated :smile: Don't mind the PR at all. I wish we had two reviewers at the moment. My part is only administration since my expertise in the coding is not yet high enough for any reviewing.

Grovkillen on 14 Dec 2017

I realy think pooling is enough for matrix keyboard.

14.12.2017 2:51 PM "Grovkillen" notifications@github.com napisał(a):

@TD-er https://github.com/td-er Your work is much appreciated 😄 Don't
mind the PR at all. I wish we had two reviewers at the moment. My part is
only administration since my expertise in the coding is not yet high enough
for any reviewing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-351716114,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOUxUe7DC0Ty57mg3QRVzJH7lWOLiHks5tASf5gaJpZM4Q_wVN
.

uzi18 on 14 Dec 2017

@uzi18 It should be enough, but I am afraid the ESPeasy architecture isn't that "real-time" enough for sampling the keypad matrix and not to miss any key.
When adding the extra pin, you can get the focus immediately and allow for a few tens of msec to sample the key pressed and continue doing the other tasks.
It may improve reliability a lot, without running the sampling function every 1/50th of a second (shortest interval in ESPeasy)

TD-er on 15 Dec 2017

Is it possible to build espeasy without platformio?

I want to add time measure and check if reading keyboard is accurate

15.12.2017 10:31 AM "Gijs Noorlander" notifications@github.com napisał(a):

@uzi18 https://github.com/uzi18 It should be enough, but I am afraid
the ESPeasy architecture isn't that "real-time" enough for sampling the
keypad matrix and not to miss any key.
When adding the extra pin, you can get the focus immediately and allow for
a few tens of msec to sample the key pressed and continue doing the other
tasks.
It may improve reliability a lot, without running the sampling function
every 1/50th of a second (shortest interval in ESPeasy)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-351957932,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOU-bcKG93tYRenESQ8_Obaih-EdNFks5tAjyDgaJpZM4Q_wVN
.

uzi18 on 15 Dec 2017

Yes, you can also build it using the Arduino "IDE".
Make sure you select the correct upload mode.
And if you checkout another branch via Git, you probably want to reload the Arduino IDE, since it doesn't detect filechanges very well.

TD-er on 15 Dec 2017

Just in case anybody is interested I purchased a HT16K33 keypad/matrix driver chip and set it up and it behaves the same. Still have to wait a few seconds between keypresses so that they are not missed. This chip is designed for this sort of thing so I thought perhaps it would behave differently. Should this be a separate issue?

Budman1758 on 16 Dec 2017

It seems P061_keypad is already scanning 50 times per second. @Budman1758 is it possible to change something on your controller so it responds faster? Which controller you use?

Also, perhaps even more important: Did you set the MessageDelay setting to 0? Otherwise ESPEasy will deliberately wait at least that many seconds between two events.

psy0rz on 18 Dec 2017

Not using any controller like Domoticz or anything.
Message delay in the keypad device page is at zero. Keypress seem to respond immediately regardless of the delay setting.

When there are no rules to process for the keypresses they register just about as fast as you can punch them in. The delay is caused by the rules processing. As they are being processed is when they are being missed. As soon as you punch in 1 key of say a 4 key code its processing that first key and misses the next ones during processing. This literally makes it take 10 to 15 seconds to enter 4 numbers and an "enter" key like # or *. There is also a short wait for the plugin (I assume) to report a zero scancode after each keypress. For each keypress the serial output reports 4 events like this......

Mkey : key=0x11
EVENT: keypad#ScanCode=17.00
((if you have rules that processing shows here. If no rules nothing here))
Mkey : key=0x0
EVENT: keypad#ScanCode=0.00

Until that last line shows up in the serial output it will not process another keypress.

Is there any way to set it up to wait for a certain key b4 processing? Much like when you enter your pin at an atm. Nothing happens until you hit "enter" I understand that it would take some major code magic for that to happen. I'm afraid that its not very user friendly as it is now. A short wait AFTER you hit "enter" is perfectly acceptable. Having to wait a few seconds between numbers is a bit frustrating because unless you have a visual indication that it "got it" you don't know if it "got it" or not.

Budman1758 on 19 Dec 2017

So what kind of rules you have that makes it so slow?

psy0rz on 19 Dec 2017

Also please provide more log lines

19.12.2017 8:43 AM "DatuX" notifications@github.com napisał(a):

So what kind of rules you have that makes it so slow?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-352664401,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOUx9uC6WAFxjq6ztq6yie_US9607cks5tB2k9gaJpZM4Q_wVN
.

uzi18 on 19 Dec 2017

And embed them using the code formation for readability.

Like this
And this...

Grovkillen on 19 Dec 2017

Ok. I did a bit of optimizing of the rules and its a bit faster. Still must wait about 2 seconds between presses tho... Rules explained.
Each keypress creates an event.
0-9 creates "number" event
"*" key creates "Send" event ( =to "enter")
"#" key creates "clear" event
"Number" event creates 2 dummy values and does the math to create a unique value for each number entry. This math was suggested by @Grovkillen. It has the effect of creating a unique value even if you enter the same numbers in a different order. So a particular 4 numbers add different for any sequence used.
"Send" event compares dummy value and if certain value sends command to another unit to make something happen.
"Clear" sets dummy values to zero for the next go round.

I don't why but everytime I paste the rules into the insert code function in this post all I get is regular text. Rules.txt attached.
Rulesupload.txt

Some log output. (level 4) Log.txt attached.
log.txt

I also have a crashing problem every so often. You can see that in the log file.

Side note... How do you get that nice code format text in this window? I use the insert code function at the top of the editor and all I get is the same plain text as all the other text in the message. What am I doing wrong? :(

Budman1758 on 19 Dec 2017

EVENT: clear
EVENT: Error: Nesting level exceeded!
EVENT: Error: Nesting level exceeded!
EVENT: Processing time:81 milliSeconds
EVENT: Processing time:4163 milliSeconds

2017-12-19 23:41 GMT+01:00 Carl Forster notifications@github.com:

Ok. I did a bit of optimizing of the rules and its a bit faster. Still
must wait about 2 seconds between presses tho... Rules explained.
Each keypress creates an event.
0-9 creates "number" event
"*" key creates "Send" event ( =to "enter")
"#" key creates "clear" event
"Number" event creates 2 dummy values and does the math to create a unique
value for each number entry. This math was suggested by @Grovkillen
https://github.com/grovkillen. It has the effect of creating a unique
value even if you enter the same numbers in a different order. So a
particular 4 numbers add different for any sequence used.
"Send" event compares dummy value and if certain value sends command to
another unit to make something happen.
"Clear" sets dummy values to zero for the next go round.

I don't why but everytime I paste the rules into the insert code function
in this post all I get is regular text. Rules.txt attached.
Rulesupload.txt
https://github.com/letscontrolit/ESPEasy/files/1573470/Rulesupload.txt

Some log output. (level 4) Log.txt attached.
log.txt https://github.com/letscontrolit/ESPEasy/files/1573494/log.txt

I also have a crashing problem every so often. You can see that in the log
file.

Side note... How do you get that nice code format text in this window? I
use the insert code function at the top of the editor and all I get is the
same plain text as all the other text in the message. What am I doing
wrong? :(

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-352908949,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOU_ZtwDwkjjRI_6H3vQ7o4fZAScfXks5tCDuqgaJpZM4Q_wVN
.

uzi18 on 19 Dec 2017

I saw that. Where? It all works.

Budman1758 on 20 Dec 2017

EVENT: Processing time:134 milliSeconds
KPad : ScanCode=0x0
EVENT: pcf#ScanCode=0.00
EVENT: Processing time:135 milliSeconds

KPad : ScanCode=0x14
EVENT: pcf#ScanCode=20.00

EVENT: Processing time:136 milliSeconds
KPad : ScanCode=0x13
EVENT: pcf#ScanCode=19.00
EVENT: Processing time:135 milliSeconds
KPad : ScanCode=0x12
EVENT: pcf#ScanCode=18.00
EVENT: Processing time:135 milliSeconds
KPad : ScanCode=0x11
EVENT: pcf#ScanCode=17.00

EVENT: Processing time:134 milliSeconds
KPad : ScanCode=0x0
EVENT: pcf#ScanCode=0.00
EVENT: Processing time:135 milliSeconds

4 keys one by one - 135 ms. per key - but no rules inserted

uzi18 on 20 Dec 2017

OK????

Budman1758 on 20 Dec 2017

For me it is ok, now i will test it with some of Your rules, but without pulse ...

uzi18 on 20 Dec 2017

As I have said before, It responds pretty fast if its not having to actually do anything after the keypress. The short pulse of the GPIO is to flash an led to show that the keypress was actually registered.

Budman1758 on 20 Dec 2017

Scancode takes 300-450 ms

my 1st task is keypad 2nd is dummy (temp)


On System#Boot Do
  Event,Clear
Endon

On keypad#ScanCode Do
  IF [keypad#ScanCode]=17
    Event,Number=1
  Endif
  IF [keypad#ScanCode]=18
    Event,Number=2
  Endif
  IF [keypad#ScanCode]=20
    Event,Send
  Endif
  IF [keypad#ScanCode]=19
    Event,Clear
  Endif
endon

On Clear Do
  TaskValueSet,2,1,0
  TaskValueSet,2,2,0
Endon

On Send Do
  TaskValueSet,2,1,0
  TaskValueSet,2,2,0
Endon

On Number Do
  TaskValueSet,2,1,[temp#a]+%eventvalue%*10^[temp#b]
  TaskValueSet,2,2,[temp#b]+1
Endon

You can see that code have normal numbers here
so You can check real code ;)

uzi18 on 20 Dec 2017

So use timers instead.
In number event just set gpio and start timer, add event to reset gpio after timer elapsed

uzi18 on 20 Dec 2017

How does that speed up the processing of the scancode? Flashing the gpio adds 1 tenth of a second.

Budman1758 on 20 Dec 2017

Looks like Pulse cmd blocks data processing.
But to be sure i need to look into pulse code.
Try to use timer

20.12.2017 1:28 AM "Carl Forster" notifications@github.com napisał(a):

How does that speed up the processing of the scancode?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-352928355,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOU6IQqSRHnpzgaRg9a2dP47TaAek4ks5tCFS4gaJpZM4Q_wVN
.

uzi18 on 20 Dec 2017

It does block. I shortened the pulse to 200 and its that much faster now. Still must wait 2 to 3 seconds between keypresses for them to all register reliably. If a timer setup can pause the "number crunching" that would be great. That would have to be done b4 the "send" event processes though. "Timing therefore probably gets a bit complicated.

Budman1758 on 20 Dec 2017

All I'm trying to do is make it more natural like any other "pin pad". Its not natural to pause between entering each number. It does work and I'm ok with it. Just trying to make it as good as it can be. After all, the plugin IS labeled "Testing" :)

Budman1758 on 20 Dec 2017

First remove or comment out pulse cmds
Test responsiveness
Try to add timer to work for your led notify
Test one more time

20.12.2017 1:42 AM "Carl Forster" notifications@github.com napisał(a):

All I'm trying to do is make it more natural like any other "pin pad". Its
not natural to pause between entering each number.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-352930638,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOU8sr7lkRHpudkTYD3Gpk8L_vwX4iks5tCFgOgaJpZM4Q_wVN
.

uzi18 on 20 Dec 2017

Hard to actually measure but its a tad bit more responsive. Still must pause about 2 or 3 seconds between keypresses. Pretty sure its the number crunching that's using the lions share of the time.

Budman1758 on 20 Dec 2017

Why do you add '.3' to the tenth? This line...

TaskValueSet,1,2,[Dummy#TempTenth]+.3

Should be...

TaskValueSet,1,2,[Dummy#TempTenth]+3

In my opinion.

Grovkillen on 20 Dec 2017

I don't know. I used the example you gave me in your forum post. Maybe I just added a period there by mistake. Does it make any real difference? Would it "speed up" the number crunching?

Edit:
I just tried that. It makes for a much larger unique number but the processing time is about the same as far as I can tell.

Budman1758 on 20 Dec 2017

Look into my rules, there is +1, dont investigate something unnecessary,
just use it as it works ok.

20.12.2017 6:43 AM "Carl Forster" notifications@github.com napisał(a):

I don't know. I used the example you gave me in your forum post. Maybe I
just added a period there by mistake. Does it make any real difference?
Would it "speed up" the number crunching?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-352970407,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOU6gJM1pYAPVzp7Lq1r5GZ3OvLJiVks5tCJ51gaJpZM4Q_wVN
.

uzi18 on 20 Dec 2017

@uzi18 yes that was my first proposal as well but @Budman1758 wanted to use the NN numbers without conversion into "real" 0...9 numbers. That is why I suggested +3. :smile:

But my suggestion is to try remove all plugins that are not needed, recompile a new binary and test. Maybe even cut down on possible tasks for the loop to be as short as possible.

Also, possible to change to another input instead of the membrane one? Just to test?

Grovkillen on 20 Dec 2017

for testing it could be +1, after resolve issue it coult be +3

@Grovkillen I have flashed dev-dev12 + clean config, added dummy and keypad plugin and it is work for me, so no recompilation needed.

uzi18 on 20 Dec 2017

@uzi18 no delays at all? rules work as intended etc. etc.?

Grovkillen on 20 Dec 2017

Yes, but I didn't tested with pulse command in rules

2017-12-20 9:55 GMT+01:00 Grovkillen notifications@github.com:

@uzi18 https://github.com/uzi18 no delays at all? rules work as
intended etc. etc.?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-353003202,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOUw-TRPlIO8lIj69TxESjv7JBHhuuks5tCMt0gaJpZM4Q_wVN
.

uzi18 on 20 Dec 2017

The pulse was only used to indicate the input with a led I suspect? I think
we should then close this issue since you could make it work? Maybe use a
timer as you suggested, and turn it on on first key press and off on
"enter/send pin"?

2017-12-20 10:04 GMT+01:00 Bartłomiej Zimoń notifications@github.com:

Yes, but I didn't tested with pulse command in rules

2017-12-20 9:55 GMT+01:00 Grovkillen notifications@github.com:

@uzi18 https://github.com/uzi18 no delays at all? rules work as
intended etc. etc.?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
640#issuecomment-353003202>,
or mute the thread
TRPlIO8lIj69TxESjv7JBHhuuks5tCMt0gaJpZM4Q_wVN>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-353005425,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZeBYpJk-vKyRgYcOBAnSVv--ldDIfM6ks5tCM2ggaJpZM4Q_wVN
.

--
Med vänliga hälsningar
Jimmy Westberg
070 65 05 709

Grovkillen on 20 Dec 2017

The 100 ms pulse was there to show you that each keypress was "seen" Starting a timer and turning it off later completely defeats its purpose. That pulse added 1 tenth of 1 second to the delay. Not much at all. I have always said that this works. The point is that you still have to consciously pause about 2 seconds between keypresses. That is not intuitive or natural. Time yourself entering a 4 digit pin plus enter and I venture a guess that you can and DO get it done in about 3 or 4 seconds. That does not work in this setup.

I have no problem with the way it works for my application. My only point here is if you were to try and market this it would probably not do very well. I'm not suggesting that I am going to do that at all, just that people in general would not be happy with it.

My question about waiting to process the entered numbers until _after_ you hit a defined "enter" key was never addressed or answered. Is or is that not possible? If not so be it. If it is that would most likely solve this entire issue.

The only other thing here is my setup is crashing on a regular basis now. I posted a screen dump up above in this thread. I can do it again if necessary. Or should that be a separate issue?

Budman1758 on 20 Dec 2017

But please verify if removing the pulse command make the unit responsive.

Also:
Given the "eventvalue=N" where N is 0...9 and use the rule Uzi gave you, you'll have the PIN in real value except backwards.

If you want a fixed number of digits in the PIN we can provide you a rule for that (making the PIN display correctly, i.e. not backwards).

" That pulse added 1 tenth of 1 second to the delay. " is correct in theory but given that the command actually is deployed in a continuous loop the delay will be more than that in practices.

Grovkillen on 20 Dec 2017

If You put like this it will be natural:
TaskValueSet,2,1,[temp#a]*10+%eventvalue%

So if You input 1,2,3,4 become 1234

uzi18 on 20 Dec 2017

@uzi18 dooh! I made it over complicated 👶

Grovkillen on 20 Dec 2017

It is _very slightly_ more responsive. But by the same token, you tend to input the numbers faster and end up where we started. The idea of the led flash is you then know the number was received.

I don't really care what unique number we end up with. This method does not require any particular amount of numbers in the "pin" number. All you do is pick a code, see what it adds up to and adjust the rule to reflect that particular number.

Budman1758 on 20 Dec 2017

Did You tried to use timer for led?

20.12.2017 7:59 PM "Carl Forster" notifications@github.com napisał(a):

It is very slightly more responsive. But by the same token, you tend to
input the numbers faster and end up where we started. The idea of the led
flash is you then know the number was received.

I don't really care what unique number we end up with. This method does
not require any particular amount of numbers in the "pin" number. All you
do is pick a code, see what it adds up to and adjust the rule to reflect
that particular number.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-353152141,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOU79Pi-kyeAEfNC8sPa_1g1R6VDEmks5tCVkIgaJpZM4Q_wVN
.

uzi18 on 20 Dec 2017

It takes 700+ ms to process a zero keypad value after you take your finger off the key. That's more delay than a 100 ms gpio pulse to flash an led.

Budman1758 on 20 Dec 2017

Did You tried to use timer for led?

No. I commented out the pulse. Did not help in any significant way. As I said in a previous post using a timer for it defeats its purpose.

Budman1758 on 20 Dec 2017

I want to measure communication time.
If i create patch could someone build bin for me?

20.12.2017 8:07 PM "Carl Forster" notifications@github.com napisał(a):

Did You tried to use timer for led?

No. I commented out the pulse. Did not help in any significant way. As I
said in a previous post using a timer for it defeats its purpose.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/letscontrolit/ESPEasy/issues/640#issuecomment-353154217,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHOUwmCfUxewKxjmSdERsIM4g4EhDCTks5tCVrrgaJpZM4Q_wVN
.

uzi18 on 20 Dec 2017

@Budman1758 I understand your frustration but we want to pin-point the actual module that is causing the problem. If it fix your overall project is a secondary subject.

Grovkillen on 20 Dec 2017

I'm not frustrated at all. Just trying to help. I don't think there is a "problem" Its just the way ESPEasy works. It just misses the keypress while its doing other things. I believe you guys are trying to chase a problem that does not exist. I personally think the plugin needs a redo. Buffer the entered numbers in memory and process them after they are all entered is how I think it should work. If that is not possible with ESPEasy then no big deal. It works as is.

Budman1758 on 20 Dec 2017

Or another way is the keypad plugin could accept a certain number of values similar to dummy values and then process those values when a user selectable key is pressed. I realize that would require a complete rewrite of the plugin and I have no idea how to do that but IMHO that would make a much better setup.

Budman1758 on 20 Dec 2017

As I mentioned a couple times this thing is crashing on a regular basis. I have a screen dump of the serial monitor I can upload. Should that go here or a separate issue?

Budman1758 on 20 Dec 2017

Well, upload the log, then we can decide whether it is related or not.

I was looking at the code of the keypad scan function and I think it can be a lot simpler and taking a lot less CPU time.
Still leaves the problem with the ESP doing other things will result in missing keystrokes.

TD-er on 20 Dec 2017

@Grovkillen @TD-er are You able to measure communication time and what is a % of overall reading of scancode?

uzi18 on 20 Dec 2017

I don't have the chip and keypad yet.

TD-er on 20 Dec 2017

Just add readings in debug level 5 just to be sure ...

uzi18 on 20 Dec 2017

@uzi18 I don't have that chip either. Sorry.

Grovkillen on 20 Dec 2017

I created a little test to see if this simpler scanning method works.
If this idea works, it could even be run a few times every 1/50th second just to make sure more scans are performed.

The assumption is that the column lines are all on the same nibble as are the row lines.
For example bit 0..3 row, bit 4..7 column.

Only functional change is that when more than one key is pressed, the result will be ignored and regarded as no keypress.
The old routine would return the first match it found.

So if anyone would like to test it?
Since I don't have such a chip & keypad, I cannot test it.

I made the builds to test it: https://www.dropbox.com/s/tr2w99jw6hfgdph/ESPeasy_issue640_test_20171220.rar?dl=0

TD-er on 20 Dec 2017

Here is that crashdump. I can test that for ya. Which chip did you make it for? Can I update the firmware or do I need to reflash it?
crashdump.txt

Budman1758 on 21 Dec 2017

Just a thought, could you remove everything on this unit so the log is not influenced by things "not related to this issue"? For example the UDP and Publish commands are active etc. etc.

Grovkillen on 21 Dec 2017

@Grovkillen I thought there is some log-level like structure already present.
Maybe we could use an issue about log clutter and a runtime (or compile-time) setting to toggle these.
It could also help reduce the heap fragmentation, since a lot of logging is String manipulation, which may cause heap fragmentation.

TD-er on 21 Dec 2017

👍1

@Budman1758 About that crashdump.
Do you have anything connected to pins GPIO 6 .. 11 ?
Use of any of those pins may lead to random crashes.

Also please try one of my test builds, I linked here, which are based on the latest point of the V2.0 branch. Perhaps it is about a bug that already has been solved.

TD-er on 21 Dec 2017

Yes I feel that we're a bit left in the dark if the unit is clogged with other "bugs" as well. I do understand the issue with processing time for the rules etc. but trying to test fixes on an not so clean unit is hard. :grimacing:

Grovkillen on 21 Dec 2017

I think the easiest way is to let the plugin collect a (specified) number of digits within a specified amount of time and if the last is set, let the plugin trigger a rule.
That still may allow for some task switching interruptions, which will cause keystrokes to be missed, but I think it is better than it now appears to be judging the posts in this thread.

TD-er on 21 Dec 2017

Yes that sounds like the best option.

Grovkillen on 21 Dec 2017

Brand new -07 module.
Flashed once with dev-12 test.
Nothing connected to gpio 6-11.
Leds connected to gpio 2, 12 and 14.
No sensors.
UDP disabled.
Only thing working is NTP.
This module does not "do" anything else at all.

As I have said numerous times the if there are no rules to process the key presses are recognized almost as fast as you can punch them in. I firmly believe there is no "problem" with that aspect of this. Its been said that the plugin scans for a keypress 50 times a second. Methinks that is plenty. The "problem" is that ESPEasy cannot "walk and chew gum at the same time". If the module is working on anything else its obviously not looking at the keypad at the same time. I watch the serial output in realtime (level 4) as I test this. Its pretty obvious what is going on. This is not really a "problem" per say. Its just the way it works.

Also please try one of my test builds, I linked here, which are based on the latest point of the V2.0 branch. Perhaps it is about a bug that already has been solved.

I updated the module with the test build for 4096 size flash. First time I entered a code it crashed. After that I did not see any noticeable difference. Still getting random crashes. Using Dev-12 normal on other modules and do not have this crashing issue. Methinks its limited to the test version.

Again, I firmly believe the "problem" is just the way ESPEasy works. The only way this is going to change is to rewrite the plugin. I think the interrupt feature of the chip needs to be implemented, the numbers collected in the plugin much like dummy values can be "inserted" and then process them all at once.

Just my 2 cents worth.

Budman1758 on 21 Dec 2017

@Budman1758 So you tested it and my code just works?
Apart from the random crashes which also happened with the old config, it just works?
I'm a bit surprised, since I had no way of testing it, wrote the code while continuously being distracted in under an hour and it uses a completely different approach.

But glad to know it works, since it is much more simple (less code) and thus better to use in an interrupt based version.
When the chip + keypad arrive, I will add an interrupt version, using the INT line.

On the other hand, my previous suggestion to let the plugin only emit new values when a number of keys are entered, will also suppress executing rules until all digits are entered. So less chance for interruptions in keypad parsing.

I don't have a ESP-07 module, so I cannot test that specific module for crashes.
Could you also test if it randomly crashes with the keypad disabled?

TD-er on 22 Dec 2017

I flashed the unit with a bin from your package. Which chip did you rewrite the plugin for? The PCF8574 or the HT16K33?

EDIT: I did an OTA update to the module with your bin file.

Budman1758 on 22 Dec 2017

For the PCF8574

You can see the changes here: https://github.com/TD-er/ESPEasy/commit/dcd2a3fc9b49996739fd7ba7facec4a995e67dfe
Green is what is added, red what is removed.

TD-er on 22 Dec 2017

OK. That is the one hooked up now. As I said, it works but no noticeable difference.

As for testing with keypad disabled I doubt it would crash. It only crashed when doing or right after the key presses. If I disable the keypad the only thing you could do is direct commands via serial or the web pages. Also, there are no other tasks for it to do. It would basically sit there doing nothing.

Budman1758 on 22 Dec 2017

having already 2 keypad plugins (PCF8574 and HT16K33) I woudl suggest to develop an unique plugin as most of those functionality would be great to have anyhow...

papperone on 22 Dec 2017

👍2

In the testing version there are actually 4
Keypad - HT16K33
Keypad - MPR121 Touch
Keypad - PCF8574/MCP23017
Keypad - TTP229 Touch
First 3 are I2C and the last looks like SPI device.

Budman1758 on 22 Dec 2017

Is still an issue @Budman1758 ?

Grovkillen on 16 Mar 2018

@Grovkillen Well. It is much faster and quite responsive. Usability is about 9 out of 10. I still think it would benefit if there was a way to store a number of keypresses in a buffer and then act on them with the rules engine. I believe is is working as well as it possibly can now so perhaps close this issue and create one for an actual plugin enhancement? But if its not possible to do it that way then there would be no point in that? There is also the question of how much demand there is for this particular use case. :)

As it is now its quite usable. It could be slightly better. :)

Budman1758 on 16 Mar 2018

Great! Will you be so kind to create a new enhancement request as described. We take that discussion there.

Grovkillen on 16 Mar 2018

Espeasy: PCF8574 Keypad plugin behavior questions.

Most helpful comment

All 90 comments

Related issues