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.

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?

Now that things seem to work: is there a really pressing reason to migrate to UIFlow2.0?

My ultimate goal is to eventually start running openHASP on them and remotely control what they display through Home Assistant, so ideally I do no extra coding, but maybe there's a security concern or something that should change my mind?

Apparently running as admin fixes the error somehow. Trying to move to a newer firmware now.

Even works without running as admin now. It did tell me an update was done and that I needed to restart it, so guessing it somehow got that patch applied with more rights and was fine after. EDIT: I celebrated too soon, without admin rights it couldn't download the firmware file, so need to run it as admin to progress. Currently burning the newer firmware.

@earla Seems to run as expected with the newer firmware, thanks for the suggestion!

@earla

Unfortunately this is what I get on the latest M5Burner software.

@ajb2k3

Right after the setup block I do an "if not connected to WiFi, connect to WiFi" if statement. I would imagine that would connect it to WiFi (and in fact I can be sure it does because I see messages arrive on MQTT when I run the bigger block of code, even if I don't see the text on screen). Am I perhaps misunderstanding you?

@earla I forgot to mention: I used an older copy of the burner program because the current one kept crashing on me saying it is missing some file. I had assumed the older one would still be able to get the most recent version to burn and I neglected to confirm that; 1.9.8 is the most recent it offers. Will look into that today, thanks for the suggestion.

It does offer to set the WiFi details, so that's what I have been using. Presumably my code would not need ssid/pass because of that?

I have been using these Core 2's for a couple of years. All I really wanted to do is move them to a different MQTT broker. The above approach used to work with even older firmware that was on there.

I have been banging my head against the following for the past few hours.

Device: Core2 running 1.9.8
Tool: UIflow (1) running V1.13.5

When using the run functionality from UIflow everything works as it should. The reason it does is that the WiFi is already connected. When I then download the code into the device it needs to connect to WiFi on a normal run. After connecting to it my label is gone and I cannot seem to find any way to get its text to show again.

As an example, this works fine using run:

Or in code:

from m5stack import *
from m5stack_ui import *
from uiflow import *
import wifiCfg
import time
import unit


screen = M5Screen()
screen.clean_screen()
screen.set_screen_bg_color(0xFFFFFF)
pbhub_0 = unit.get(unit.PBHUB, unit.PORTA)






Status = M5Label('Status', x=0, y=0, color=0x000, font=FONT_MONT_26, parent=None)


if not (wifiCfg.wlan_sta.isconnected()):
  wifiCfg.autoConnect(lcdShow=False)
while True:
  Status.set_text('0')
  wait(1)
  Status.set_text('1')
  wait(1)
  wait_ms(2)

Using download and letting the device start the program this shows the WiFi connecting and afterwards nothing happening on screen. If need be I can draw stuff on screen through the graphic blocks, including text, but my label remains gone.

Things I have tried:

• pretty much anything in the label section
• setting the background color
• Lcd.clear / Clear screen (followed by pretty much anything above)
• using the disconnect from "Original Network Function" and then a connect in hopes I can make this reproducible when using 'Run' (no luck) so I can at least diagnose it more easily

I'm out of ideas, does anybody have any idea what might be going on?

@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.

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.

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?

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).

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.

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?