GPIO ports for the grove connector?

cerietke

To be honest, when soldering gets involved it's probably the wrong direction for me, that said, if it works for others I don't mind having it in the discussion. Also this makes the Core2 come forward a bit, I have at least 1 location where there is no room for that.

I believe the standard port A grove connector uses GPIO 32 and 33, which I guess means at least 1 extension could be connected, not sure what happens if a hub is connected and it gets a general 'on' signal.

While not ideal I think I could make things work for me with a single relay, still it would be far nicer if there was a way to incorporate all the extension modules.

bschwahn

@cerietke

I totally understand about the soldering. The quality of my soldering skills has diminished drastically along with my vision 😉

Ok, was really hoping someone with more experience with the Core 2 and Grove interface would step in here as I am a newbie yet here I go.

I don't believe the Ports can be used as standard GPIO. The Ports are used as IC2 Ports for serial based communication. Yes, the ports are connected to specific GPIO pins as you stated but are controlled by software for serial communication. I can't see how via UIFlow that you can treat the PBHUB as a standard GPIO.

Again now that I have commented that someone who is an expert will point out if I am correct or not to help you on your project 😉

felmue

Hello guys

M5Stack has defined three Groove ports A, B and C.

A (red) is by default used for I2C (found on M5Core2)
B (black) is by default used for DAC / ADC (found on M5GO Bottom2)
C (blue) is by default used for UART (found on M5GO Bottom2)

that said, from the perspective of the ESP32 almost any GPIO can be used for any function. Or in other words the above is not set in stone, but only what M5Stack has decided to use as their default.

So, yes, you could use the two GPIOs on port A as standard GPIOs. In Arduino you'd just wouldn't initialize I2C on these two pins and then you could use for something else.
In UIFlow that would happen (automatically) if for instance you attach the relay unit (which is an UART device) to port A and then use the respective relay blocks.

Regarding the PbHub: this is an I2C device which by default is plugged into port A. It has 6 ports, each providing an input and an output. These 12 pins are controlled by an microcontroller inside PbHub and the available functionality is limited to a given set. Check the list at the bottom here.

Now, in Arduino you use this library which takes care of sending the proper I2C commands to lets say turn on the output pin on PbHub port 1. Or read the input pin on port 6.

In UIFlow if for instance you connect the relay unit to PbHub port 2 (instead of directly connecting it to a Groove port) you then use the PbHub specific block to control the 6 ports on PbHub. Again which I2C command that requires to be sent to PbHub is done automatically by the UIFlow firmware.

So, for your project, @cerietke, using OpenHASP, the OpenHASP firmware for M5Core2 would need to know about PbHub to be able to control the ports on PbHub. I don't know anything about OpenHAB so I cannot tell if it could deal with PbHub or not. That is probably an question on the OpenHAB forum to ask.

Thanks
Felix

cerietke

@felmue Thanks, that cleared up a number of things. In essence I believe this means I can only use the one grove port, theoretically splitting it into 2 because there are 2 pins at most. Unless of course the library was added to openHASP in some way. Unfortunately they don't seem too enthusiastic about that and I don't have the ability myself.

(I think you mean openHASP rather than OpenHAB in the last paragraph)

bschwahn

@felmue

Awesome Felix!

Thanks for responding and clearning this up! Your response reminded me that I made the assumption that all Core 2 configurations are using the M5GO Bottom2 (which sorry to ceerietke as that may of confused you) which is not the case.

With that said you could remove the base and have direct access the GPIO pins directly inside the CORE 2.

cerietke

(I set up topic watching, but got nothing :-()

I indeed don't use the bottom. I have a height limit in one of my locations of placement.

cerietke

I've been trying to connect several devices and use them through the grove connection. LED, normal relay and solid state relay. I've tried both GPIO 32 and 33, but no luck. I did get openHASP to report the device status change, but I saw no evidence of an effect. Could I be making a wrong assumption that these devices could be directly manipulated from the GPIO this way?

felmue

Hello @cerietke

it is not very intuitive, but I managed to turn GPIO32 on and off. Here are my steps:

download and flash m5stack-core2_full_16MB_v0.6.2.bin onto M5Core2
setup wifi connection (check M5Core2 has connected)
setup mqtt connection (check M5Core2 has connected)
setup gpio output
Pin: 32
Type: LED
restart M5Core2 (so all gets properly subscribed and published)

Now send an MQTT publish command to turn GPIO32 on / off:

On:
Topic: hasp/plate/command/output32
Payload: "{\"state\":\"on\",\"val\":\"255\"}"
Off:
Topic: hasp/plate/command/output32
Payload: "{\"state\":\"on\",\"val\":\"0\"}"

Note: I did not manage to turn the output on/off by manipulating the state value. Only changing the dim value from 0 to 255 and back worked for me.

Thanks
Felix

cerietke

Hi @felmue
It's really finicky, doesn't always take the GPIO config after a reboot, however I did finally get the state to change. So thanks! Unfortunately it has no observable effect on the connected modules: whether it's on or off, nothing changes. I found it doesn't matter whether for state I send it on. off or anything else.

https://shop.m5stack.com/products/mini-3a-relay-unit

I have this one connected; one power cable* connected to 1 input on a socket for a light, two power cables with the relay in between for switching. The latter cables connected on NO and COM of the module and the other input on the socket. The other ends of the cables are connected to a power plug.

When I connect the module to the M5 Core2 it powers on the light, disconnecting or powering of the device results in the light going off. Changing the state between on or off though by using the method suggested has no effect on the light being on or off. I believe it should if things were working correctly. (This is also close to what it will be doing once placed).

* I am not too familiar with electricity and not a native English speaker, it could be that I say cable where I should say wire or something, I mean 1 length of single copper (?) core coated in plastic.

felmue

Hello @cerietke

ok. I think you got the light wired correctly. And the relay unit also uses GPIO32 so in theory it should work. It is interesting that by connecting the relay unit to the M5Core2 makes the relay to switch on. I am saying this because normally after a reboot GPIOs are in LOW state, but in your case it seems to be in HIGH state else the relay would not switch on. Hmm.

Have you looked at the serial console output of the M5Core2 with a terminal program on your computer? OpenHASP firmware is quite talkative. It might shed some light on what's going on.

Also have you tried to switch the relay on and off w/o OpenHASP, e.g. using UIFlow firmware instead?

Thanks
Felix

cerietke

I've used the LED and relay before in UIFlow and have seen them work just fine. In fact I have a number of M5 Core2's in use with relays and leds right now. I am testing on the AWS version, while the others are normal, but I thought the only difference there was the AWS chip?

I've not tried connecting through a terminal program before. I'm assuming I need to turn on the debug stuff and just use putty to connect? (Not currently able to try; at work).

cerietke

0_1643211935285_d3715909-ea6c-460e-bde0-cb9de8c97220-image.png

First arrow: every now and then it crashes and loses the GPIO config.

Otherwise these read to me as normal messages?

I tried sending the on/off through serial as well, also no effect. Tried adding a group, also no effect.

Now this is interesting: after I tell it through serial to reboot it starts on off AND the light is off.

0_1643212811830_d010159a-001d-428c-8f0a-7e26d88429eb-image.png

I can turn it on, but after that I can no longer turn it off :S.

I see the same if I do the reboot and "on" from MQTT.

So positive: it appears that it can control the relay to some extend. But how do I get it to turn off and how do I regain the ability to change the state?

felmue

Hello @cerietke

yes, those logs seem ok to me - not sure why you cannot turn your light off though. Like I wrote before I had a similar issue until I changed my commands and used the dim value instead of the state value. Hmm, running out of ideas here. Sorry. (And no, I did not have to add a group.)

Thanks
Felix

fvanroie

Hi all 👋, I'm the creator of the openHASP firmware. Thank you @cerietke for starting this topic and providing the link to it. Reading over this thread I get a much better view on the hardware questions and how these devices are supposed to work together.

Unfortunately I don't own a Pb.HUB or these sensors myself... Hence my reluctance of adding support in the firmware as I have no means of testing it myself. I'm truly sorry if this came across as being indifferent to your questions. We are happy to help out all openHASP users from beginners to developers!

I do own several M5stack devices but I've only tested the M5Stack core2 standalone. With the Arduino library that @felmue posted it should be possible to add that driver for the Pb.HUB. I see two routes:

either a custom add-on where the hubs gpio are exposed via MQTT only or
officially add the device to the firmware and add it the Web UI, MQTT, etc... like normal GPIOs

Option 1 can be done by any developer with access to the hardware, while option 2 will take more effort and testing because it requires changes in several modules of the firmware. It also means I need to have access to the hardware.

As for the GPIO issues, I can not see the problem from the logs posted above. But I have seen another post about not being able to turn an output off. So I'm left thinking there is a bug in the command parser or the documentation isn't clear...

I will wip out my core2 to do some tests and keep you posted.

felmue

Hello @fvanroie

thank you for your insight and thank you for looking into the issue where an output cannot be turned off. Much appreciated.

Thanks
Felix

fvanroie

@fvanroie said in GPIO ports for the grove connector?:

So I'm left thinking there is a bug in the command parser or the documentation isn't clear...

I can confirm that this problem is a parser bug. It currently only accepts unquoted boolean values of true/false or 1/0 instead of the usual range of: on/off, true/false, 0/1, yes/no which might be quoted or not.

This is particularly confusing since the state is always reported as on/off.

Thank you very much for bringing this issue to my attention. I have pushed a fix to GitHub and it is available for testing from the Actions tab and updated the documentation.

felmue

Hello @fvanroie

thank you for confirming the issue and promptly providing a fix.

I've tested the updated M5Core2 firmware (m5stack-core2_full_16MB_v0.7.0.bin) from the Actions tab and can confirm that the issue has been resolved.

I can use the following state values successfully now:
"on" / "off"
"true" / "false" or true / false
"1" / "0" or 1 / 0
"yes" / "no"

eg. a payload only containing a state value (and no dim value) works now for me
"{\"state\":\"on\"}"
"{\"state\":\"off\"}"

Thanks
Felix

cerietke

@fvanroie said in GPIO ports for the grove connector?:

Unfortunately I don't own a Pb.HUB or these sensors myself... Hence my reluctance of adding support in the firmware as I have no means of testing it myself. I'm truly sorry if this came across as being indifferent to your questions. We are happy to help out all openHASP users from beginners to developers!

They're pretty cheap, I'd be happy to purchase a few for you if that would be useful? You're Dutch as well, right? Send me a PM here or on github if interested. I'd understand if you wouldn't want to get distracted from the main focus of your project though.

Personally I wouldn't mind the MQTT only route as that's essentially how I'd be using them, however it would be nicer if it was built in.

I was going to post here to report on the issue having been found, but nice to see it already was :-). It seems to work for me with true/false or 1/0, working, so can't extensively test.

fvanroie

@cerietke said in GPIO ports for the grove connector?:

Personally I wouldn't mind the MQTT only route as that's essentially how I'd be using them, however it would be nicer if it was built in.

It's not really about being nice to have but rather the benefit vs. time to develop, test and support this feature. Normally there is a discussion on Github or Discord (or this forum). Then if there is enough interest from the community we add a feature request on Github and see who can implement it.

Note that there are numerous other ideas and requests floating around, so this will take some time. The only way I see to expedite your request is to try coding this as a custom plug-in first...

If there were more core2 users of openHASP that could go faster but I don't see that currently. Maybe it's a bit like the chicken and egg problem. I might consider posting about openHASP in the Projects section to gauge interest.