GPIO ports for the grove connector?

bschwahn

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.