KeyHive Sofle RGB w/ nice!nano v2 Issues

[cursive stone]

I bought the Sofle RGB from KeyHive. This is my first build and I am learning that somehow this version of the Sofle is not in line with the original or its other derivatives. Read an article by who i believe is the original designer of the Sofle keyboard saying:

Update (22.8.2021) - Sofle RGB by Keyhive
Only after I published the article, I learned that one particular vendor - Keyhive - is selling their own fork of Sofle RGB. This version is modified in way that makes it incompatible with the firmware for the official designs. You have to use the firmware provided by the vendor and build guide provided by them as well. Please, don’t report problems with the desing and or firmware to the official Sofle github repository. Their modification is not part of the repository and therefore we cannot fix the problems or help you with solution. Contact the vendor instead. You are their client, in the end.

I got stumped on the firmware after soldering the majority of the left-half of the keyboard. On the Sofle RGB page of the KeyHive site (linked in the first sentence of this post), they state that the nice!nano controllers can be purchased separately and used.

However, nice!nano is not compatible with QMK. I learned this after I purchased 2 of those pricey things. I proceeded to try using ZMK-based firmware I found for the sofle but I end up with the keymap inverted somehow. Moreover, the LEDs don't work and i'm not even sure if thats my fault or some incompatibility with ZMK.

I would appreciate any guidance here. I reached out to keyhive support on this issue but I haven't got a response yet. I have ordered some Pro Micros to use QMK instead but i'm still pretty disappointed with the purchase, feeling like i got the ugly duck of Sofles.

[static mirage]

Hey, sorry to hear about your troubles. Keyhive doesn't seem to do anything to officially support ZMK on their keyboards, even though they sell the nano with the keyboards

A user has opened a pull request to add support to ZMK here: https://github.com/zmkfirmware/zmk/pull/1233. Hopefully that would get merged and you can use it.

However you can also try it before it gets merged, by using it as a custom shield definition. To do that you can copy this folder https://github.com/maximus5684/zmk/tree/feature/sofle_rgb_keyhive/app/boards/shields/sofle_rgb_keyhive to the path config/boards/shields/sofle_rgb_keyhive in your existing config repo, then change sofle* names in your build.yaml and sofle.keymap, sofle.conf to sofle_rgb_keyhive*

[cursive stone]

Thank you! I will try this and report back.

[cursive stone]

I am a bit confused on your instructions. I have copied the directory from his fork for sofle_rgb_keyhive into the boards/shields/sofle_rgb_keyhive directory i created for the zmk_config file.

When you say to change sofle* names you specify to change names in sofle.keymap and sofle.conf. But there is a sofle_rgb_keyhive.keymap and .conf file already from the directory i copied. Do these get replaced? For example, do i need both the /config/sofle.keymap and /config/boards/shileds/sofle_rgb_keyhive/sofle_rgb_keyhive.keymap?

[static mirage]

Yes, if you have config/sofle_rgb_keyhive.keymap and conf then they will override the ones in the shield folder.

At that point you shouldn't have a config/sofle.keymap and conf files, since the keyboard name is different

Also when you say you put them in boards/shields/sofle_rgb_keyhive, this boards folder is under config/, right?

[cursive stone]

yes, under config/ in the "zmk-config" directory (mine is named zmk-config-sofle)

[static mirage]

Also don't forget to change the shield: values in build.yaml

[cursive stone]

ok so the .keymap and .config in the /config directory will override those with the same name in the boards/shields/sofle_rgb_keyhive directory? If so, should i just remove my own so that it defaults to the ones i copied from his fork?

[static mirage]

They will override,yes. But you want your own keymap and not the default one, no?

Unless you have issues in your keymap that you don't want to debug at the moment, I'd recommend you rename your sofle.keymap etc. and have it override the default. I think the keymap should be compatible between Sofle and the Keyhive version?

[cursive stone]

Well i'm assuming he has those fixed which is why he created the new shield specifically for the keyhive version of the sofle, separate from the sofle shield that already exists in the main zmk (which is probably for the original sofle).

Does that make sense?

I think the issue isn't with the keymap file itself but the lower level firmware that defines how the nice!nano connects to the pcb.

I'm new to this so i could be wrong on how i understand terms and how the firmware works

[static mirage]

OK I understand what you mean: The dtsi and overlay files in that folder are what defines the hardware properties of the keyboard. The keymap in that folder is a default keymap, that the user is expected to copy and modify to their liking. The pin definitions etc is abstracted away from the keymap -- as long as the number of keys per layer, number of encoders etc. matches what is defined in the hardware, it is up to you to customize

However like I said, if you just want to see it working first, it might be a good idea to build with just the default keymap for now

[cursive stone]

Ok so i have partial success. The keymap is no longer inverted so it seems. However, the LEDs are not on

[static mirage]

For that, you likely want to copy config/boards/shields/sofle_rgb_keyhive/sofle_rgb_keyhive.conf to config/sofle_rgb_keyhive.conf and uncomment the underglow configuration in it

[cursive stone]

# Uncomment the following two lines to disable the underglow LEDs
# CONFIG_ZMK_RGB_UNDERGLOW=n
# CONFIG_WS2812_STRIP=n

wouldn't that do the opposite?

[static mirage]

That's interesting, that's not how they are usually set up

let me take a look

That seems wrong, I don't see where else they enable it by default either. I'd change it to following and then uncomment:

# Uncomment the following two lines to enable the underglow LEDs
# CONFIG_ZMK_RGB_UNDERGLOW=y
# CONFIG_WS2812_STRIP=y

[cursive stone]

that's what i was thinking. Ok i'll report back in a few.

still no luck

[static mirage]

Do you have an underglow toggle key in the keymap like &rgb_ug RGB_TOG or &rgb_ug RGB_ON? If so, you can try toggling it on

It could also be a soldering issue if you haven't tested the LEDs before

Also can you send a link to your config?

[cursive stone]

I don't see anything like that in the keymap file.

The only equipment i had to test the LEDs was a multimeter. I used the diode setting and i got values which i assumed meant connectivity. I know one of them is wired upside down. Do they work like the strips? If one is inverted it might prevent current from going through the rest? And well if that one is the first led in the chain then none will light up?

The other thing is that there is two sets of rgb. One for underglow and another for the per-key backlighting

the one soldered incorrectly is the one for underglow

https://github.com/rluna319/zmk-config-sofle

It was originally a fork from a different repo. Everything was replaced per your instructions though. I will take the time to remove that dependency later.

[static mirage]

Yeah, it might be worth adding those bindings to one of the layers: https://zmk.dev/docs/behaviors/underglow

So the way this shield is set up is that underglow and per-key LEDs are in a chain, with underglow LEDs coming first. If any LED on the chain is broken the rest of the chain will not work

This is the ordering of LEDs https://github.com/keyhive/build_guides/blob/master/docs/keyboards/sofle-rgb.md#solder-underglow-leds

For instance if the first LED in the chain is upside down, none of the LEDs will work for that side

There could be other issues with the soldering potentially but I have no experience debugging them with a multimeter myself

[cursive stone]

so yeah this one is the one soldered upside down i think. Let me fix that.

I would also like to thank you so much for being this much help. I have been at a loss here and you are helping me make good progress.

[static mirage]

No worries, hopefully everything will work out 🤞

I am low key annoyed at vendors who think they are just in the hardware business

Only a few good ones do the right thing re: firmware support. Sometimes the best you get is a VIA hex upload

Since ZMK is more niche, they care even less

[cursive stone]

Yup, i was completely unaware of this being a thing. I had no idea of the variants of this keyboard much less that this vendor was selling its own fork of the original design. I was so upset yesterday evening. I ordered some pro micros so i can use QMK but maybe if i can get this working i'll just return em.

[static mirage]

Yeah, I get that if they just sell a Corne kit, they don't need to care about firmware much

But if you change a standard design and claim it is n!n compatible etc. you should give firmware support some thought

[cursive stone]

Is this because the firmware is well maintained?

[static mirage]

It is a standard open source design that is very popular, so any firmware will already have support for it

[cursive stone]

I see. Well you live and you learn. I know now what to look for when shopping for my next build.

I am going to start on fixing the soldering. I'll report back later when i do that and re-flash the firmware.

[cursive stone]

so i messed up the pads on my board 😆 looks like no leds on the left half till i repair it. Going to put together the right half and test that side with leds

[static mirage]

It’s OK, LEDs are useless anyway ducks

[cursive stone]

i put the right side together and flashed the firmware. Doesn't work. I connected the trs cable with usb-c plugged into left half. Tried the right side alone with usb-c. No output. I flashed the left side firmware to the right side. I can type i get output. So i'm not sure if this is just a firmware thing. Also no LEDs

[static mirage]

Right side only works by sending key presses to the left half. so you need to have left half running and connected first

Since you flashed left half firmware to right, you need to go through this procedure to get the two halves to pair to each other: https://zmk.dev/docs/troubleshooting#split-keyboard-halves-unable-to-pair

Also don't use TRRS, it isn't used for communication and it can break the nanos. If you need to power the right side without battery, use the USB port

[cursive stone]

interesting. is there a chance i already messed them up?

[static mirage]

It is likely OK, and most likely you need to pair the two halves properly

[cursive stone]

In the process of doing so per the guide you sent.

ok so i have the halves paired now and the typing works. I also have some LEDs on the right half working...but it doesn't seem right idk if this is firmware or soldering

[static mirage]

What is not right exactly?

[cursive stone]

not all are lit but also when i move it around it switches colors randomly

Do you think this is soldering?

[static mirage]

I would guess so, but I would still try toggling it off/on to force a sync. You can also try changing hue, saturation, mode etc.

[cursive stone]

LEDs 5 and 6 are not lit but 7 is which means there is some connection in the chain i think?

[static mirage]

Maybe the Vcc GND is connected well but not the data pin? I don't exactly know

[cursive stone]

i apply light bend to the pcb and 5 and 6 turn on

[static mirage]

Sounds like a soldering issue yeah

[cursive stone]

ok

i will try to fix thank you though. I'm happy the actually keyboard seems to working. Just wish it could all go smoothly 😩

[cursive stone]

ok so i fixed one problem. I believe there is connectivity throughout the chain. i see all the leds on up to the last one but there still that glitchiness with the lights. It changes when i move the controller i think because the board isn't soldered on. its sitting snug with the pins it came with. I don't want to solder the board and i didn't buy sockets. So i think i'll buy sockets and in the meantime just turn LEDs off and see how the keyboard works

[static mirage]

Yeah, makes sense. You should also try turning the brightness down: You have so many LEDs that it might not be drawing enough power for all of them

I am really not a fan of LEDs in wireless keyboards anyway, they consume too much power even when off

[cursive stone]

Yeah i wasn't really thinking all too much on power when i purchased this board. I honestly plan on using it wired majority of the time. But i like the idea of being able to take it and use it wireless the few times it might prove useful

[cursive stone]

im having trouble with the encoders. I have done everything in the docs and checked all the files to make sure everything is correct. For whatever reason. the left encoder is doing the bindings for both left and right and the right encoder does nothing

[static mirage]

Right encoders are currently not supported https://zmk.dev/docs/features/encoders

I am guessing some things you tried in your config might have caused left triggering both

By default it shouldn't

[cursive stone]

I missed that bit.😆

[marble mulch]

I'm using a fork by infused-kim that enables the other encoder.

On a Klein split with Xiao BLE MCU

[cursive stone]

i saw that as well. As soon as i have everything the way i want on this keyboard i think i'll trying doing a build using his ZMK fork.