Hi @Schorsch,

Hmm, that's a little frustrating on the RFID front. I can only assume it's in progress with M5Stack for release (I couldn't see it either in UIFlow2).

I had a look at the Hackster project, and I think they've been a little tricky with the hub implementation. If you look closely at the images the hub appears to be the 1-to-3 Hub (which operates differently to either the PaHUB or PbHUB).

I think they have connected the Servo and PIR to the hub Groove connector:
Pin 1/White input from PIR (Pin 2/Yellow not used)
Pin 2/Yellow output to Servo (no Pin1/White)
5V and GND in parallel. Connected to GPIO Port B (Black) on Core.
Then they've gone for the PaHUB (PortA-Hub) I2C (Red) to connect the other sensors.

I don't think you will be able to daisy chain your Servo via the PaHUB because it is I2C not GPIO. The good news is the CoreS3 has more ports to play with. Looking at the very tiny image on the CoreS3 documentation, I think Port B GPIO (Black) I/O is on G8/G9 respectively i.e. connect output/G9 to the control line of your servo.

Port Pin NOTE
PORT-A(RED) G2/G1 I2C
PORT-B(BLACK) G9/G8 GPIO
PORT-C(BLUE) G18/G17 UART(RX/TX)

It might be worth a try with your servo connected to Port B GPIO (Black) then introduce the other hardware.
G8/I (White) --> Not connected
G9/O (Yellow) --> Servo control
Red--> Red
Black --> Black

And then try the PWM blocks in UIFlow2 Blocky with some pauses in between. I don't know what the duty and frequency will be for your servo, so I've shown values copied from the Hackster example.

Shout back if you can at least get some movement out of it. Best of luck.

Hi @Schorsch,

[UIFlow2 environment assumed CoreS3]

In the original UIFlow there was the following under Advanced > Pin Servo
https://docs.m5stack.com/en/uiflow/advanced/pin

However, in UIFlow2 I can't seem to locate the same. Under Software there is the MQTT and other stuff from Avanced. And I couldn't see it under Hardware either, but there is PWM to directly control pin outputs, which might be an option, if you can confirm the servo values.

An alternative thought, switch to Python window in UIFlow2, add equivalent lines from UIFlow and see if the Servo library and function can still be called outside of Blocky
e.g.
from servo import Servo

servo0 = Servo(26,50,500,2500,180)
servo0.write_angle(90)
servo0.write_us(1500)

And some more here
https://github.com/m5stack/M5_Hardware/tree/master/Structure

Hi @leoagro,

The M5Burner software can recover most things (we've all been there). I suggest start from the M5Stack website for your device to try bringing it back to basic functionality first i.e. take your Core back from Core2 firmware.

If you still have trouble post back here with the environment you used to flash the firmware, recovery steps taken, etc.

Hi @rob-driver1970,

For comparison, this is mine for AWS MQTT.

@dumitru,

See https://docs.m5stack.com/en/product_i2c_addr
I think you might have a clash either way:

Depending on chip, ENV III (QMP6988) with PaHUB:
Or ENVIII (SHT30) and the cradle base with the SHT30 in it.
https://shop.m5stack.com/products/btc-standing-base-for-m5-core-with-sht30
"Once M5Stack Core has been attached to BTC, it can not connect to an ENV Unit. This is to avoid I2C address conflict with built-in SHT30 sensor of BTC Base."

ENV III UNIT
0x44(SHT30)
0x70(QMP6988)

PM2.5
0x40(SHT20)

DLight UNIT
0x23(BH1750FVI)

M5Core
0x75(IP5306)
0x68(MPU6886)
0x6C(SH200Q)
0x10(BMM150)

PaHUB UNIT
0x70(TCA9548A)
PaHUB2 UNIT
0x70(PCA9548AP)

You can confirm chip on ENV III from the sticker on the back. If conflict is with SHT30, try with Core out of the cradle.

Hi @dumitru,

Maybe from the UIFlow examples?

e

Hi,

I'm not able to assist on this one directly, but I wondered if it would help to outline what you are trying to achieve a little more.

AtomS3 --|
AtomS3 --|
AtomS3 --|
AtomLite or Matrix? -|

Which is the main processor?
Are you using UART or I2C for communications?
Are you thinking I2C from the 3x AtomS3 via PaHUB to Atom (as central processor)?
Are you thinking UART from the 3x AtomS3 via PbHUB to Atom (as central processor)?
If using I2C, might it be possible to change addresses of each device and connect on a common bus (Atom Master -| 3x AtomS3 Slave)?

Continuing my tale-of-woe about the PaHub:

I have now tried using G0 and G26 (StickC) to connect as custom I2C to PaHUB with the ENV III attached, which works on Port A.

Via the PaHUB using the top hat pins (the pins an I2C hat uses). I get "Pahub unit maybe not connect", fine on Port A.

Hi @rambinator, Yeah, I missed the 2x, very sorry.

Let's try again. I've got some kit, so I'm going to try and see where it takes us.
Home > Store > Sensors > Hat(s) > ENV III – the picture gives G0 I2C-SDA, G26 I2C-SCL

I have the ENV III unit, not hat, so I used a Groove2Dupoint and made the connections to I2C on the unit (plus 5V and GND). In UIFlow, I added the unit on custom pins 0 and 26 and made the simplest temp label 1 sec loop. Run and temp reading appeared, nice.

Next I have the PaHUB (I2C-to-I2C), so I added the hub with custom G0 I2C-SDA, G26 I2C-SCL and ENV III to PaHUB|#0
Run and "Pahub unit maybe not connect", not shocked – read my other posts.

Switch PaHub from custom GPIO to Port A (bottom), Run and ta-da temp reading ok on screen via the hub. And that's my concern for you with the PbHUB option (my issue might just be because I2C devices/PaHub). Now, the hub is quite cheap, so you could try it, maybe use Port A and put the 8-encoder on the top (custom pins 0 and 26).

There are 3 pins at the top (0, 26, 36), which I would have said should suffice for proto hat option. However, I don't think all the PIN ports at the top are the same. I'm speculating here – @felmue help please – but I think the following for I2C.
G0 - Fine SDA/SCL
G26 - Fine SDA/SCL
G36 - Couldn't find the unit because it's ADC, but it might be fine for the limit switch, risk with the angle units.

In conclusion, I'd go for the PbHUB try it through the hat connection G0, G26, and connect angle units (GPIO) and limit switch (GPIO) to it. Use the bottom Port A for the 8-encoder. If you get error messages about the hub, swap top to bottom (fingers crossed).

PS You might want the proto hat as well. The Dupont to top of StickC next to each other are a little tight. Might also save you the buy of Groove2Duponts because you will get one cable with each device (cut one in two to give bare cable to Groove).