Tasmota: MGC3130 gesture chip support

Created on 12 Sep 2018  Â·  17Comments  Â·  Source: arendst/Tasmota

I recently got my hands on a "SKYWRITER" board from Pimoroni and wanted to give it a go in TASMOTA.
It as based on the MGC3130 from Microchip, which is an electrical near field sensor for gestures and 3D positions. All computations are done on this chip and we "only" have to read out the desired values via I2C.

The biggest CON is the price as a complete board (> 25€) is way more expensive than our usual SONOFF device.
Light CON's are the need for 4 free GPIO's and to deal with loads of data, which IMHO is not trivial (stress for the I2C-bus and the messaging system, filter and do actually something useful with it). Of course you have to keep in mind electrical noise.

PRO's are loads of data:smirk: (various flick- and touch gestures, airwheel and X,Y,Z-positions) and the possibility to hide the sensor behind different materials.

If you have such a board, can try out a WIP driver on my repo:
https://github.com/Staars/MGC3130_for_tasmota/tree/master

I will try to improve the driver anyway but if there is public interest, then I could do a PR in the future. So the "Issue: Feature request" is more a question from my side.

enhancement

Most helpful comment

Cool, I hope you will not be disappointed.

It would be nice to get a real-world-response before I do a PR, but I have to clean up some things before anyway.

@ascillato2 For a PR I would have to introduce 2 new GPIO‘s (transfer- and reset-pin). It is not necessary to give them device specific names and we good use generic names, which could be used for other sensors/drivers too (irq, reset, ...).
This is more a strategic question and there is no strict right or wrong (I guess).

All 17 comments

Nice

Please, when you have the driver ready, do a PR. Thanks.

@Staars
Question:

It is the version without HAT, look here:
https://shop.pimoroni.com/products/skywriter

@Staars
Thank You for the link.
Wow, must have it and will help to test so far i got it in europe.
Amazing stuff.

That can help people who has issues with walking or stand a longer time.
I have seen your struct for the touchInfo. Very interesting...

BTW:
I found something about a FM radio for arduino but the source
code can be changed for the ESP8266/ tasmota. WIll have a look.
Ha it is so much fun to work witth it.

Cool, I hope you will not be disappointed.

It would be nice to get a real-world-response before I do a PR, but I have to clean up some things before anyway.

@ascillato2 For a PR I would have to introduce 2 new GPIO‘s (transfer- and reset-pin). It is not necessary to give them device specific names and we good use generic names, which could be used for other sensors/drivers too (irq, reset, ...).
This is more a strategic question and there is no strict right or wrong (I guess).

@Staars
The board will here tomorrow and possible in the weekend i have time after
i changed some code for the other project, mp3 player, then you will get a
response.
The real world app is e.g. the mp3 player and some other things for me.
I have a very strong L4/L5 hernia that hearts me 24/7 and how more i
move how more pain i have. So is that real enough?

And to dissapoint me you need much more stuff, realy strong stuff.
Never lost my black humor, in germany they name it sarkasm.

@Staars
I have seen in your code that you had tested or basicly implemented
the serial message part. That is one i need because i have no mqtt
running because i don't needed for my plc systems. But for others is
that ok.

Code addion:
Can you add #ifdef USE_SERIAL_DEBUG_SKYWRITER, or will be
the sprintf() part 100% implemented so as normal?
For the mqtt part, It coud be ifdef MQTT so as in the other drivers.
But we can talk about it on discord private or hangouts.

Or have i seen this worng? Can be it was to early in the morning at 02:30am.

My initial idea is to:

  1. transmit the messages via mqtt to whatever you like (Node-Red or something)
  2. be able to use RULES on device , that should already work.

But I am completely open to other ideas. Can you point me to a specific part of an actual driver, that showcases the desired implementation (of the serial stuff)?

My plan (in that order) is:

  1. Split up the modes. My current idea is to have gestures, airwheel and position modes. The touch mode shall always be active to have the possibility to switch between modes on device (with RULES). A sensible usability of the position mode has to be seen, because if you want to touch the device for a mode switch, you have to move your hand.
    There a a few things to consider, to have a usable GUI (gesture user interface :sunglasses:).
  1. Filter the TAP-messages. I want to omit the TAP before the DOUBLE TAP, which seems to be only possible, if I delay the TAP-gestures with a time out.

  2. Implement other (your) ideas if possible.

@Staars
The package was not delivered today about a mistake in the shop, grrr.
It will be tomorrow i hope...

All the other things later. ;-)

No hurry ;)
I did an update and implemented different modes (gesture, airwheel, position). The README should describe how to use it incl. an example for RULES.
@mike2nl (or whoever is interested) Maybe we can discuss minor and different things on my repo and report only the bigger changes in this thread. When a PR is done this repo will be removed and we return here.

@Staars
we can talk over discord. It's faster and driect. we can message ech other and so on.
I don't know who has top give you an invitation or you need one.
Search the wiki for it i think there you will find the link.
-> here is the link: https://discord.gg/Ks2Kzd4

BTW:
my skywriter arrived 15 minutes ago, yeah.
Looks cool, the board self, some pins to solder them and
4 feets to lift the board about 2 mm from the ground.

New beta:
Added duration value for touch gesture, which can be used in RULES.
Only publish postion data for the upper half of the z-range (this reduces the z-rang), so you can move your finger near the surface, without producing data. That should make it more usable, as there is a safe volume now.
README is updated accordingly.

@Staars

Hi,

Any news on this? Can you make a PR for this?

Hi, technically it is possible to make a PR. I would only have to add 2 new GPIO's to the (already long) list.
To be honest, I had hoped that someone can confirm, that it is easy and repeatable to get this sensor to work outside of my test setup and to get some input and ideas from other users.

I can do the following:
-check my driver with the latest TASMOTA version and if successful ...
-make the PR

This will probably happen in the next 3 days.

:+1:

Closing as the PR #4404 is done.

@Staars Thanks a lot!!!

Was this page helpful?
0 / 5 - 0 ratings