GPIO ports for the grove connector?

felmue

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.