HHKB YDKB Yang BT Controller

[jram0421]

Description

Adds support for the Yang controller for HHKB Pro 2.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[Erovia]

Personally, I'd rather have this implementation under keyboards/hhkb/yang than in its own directory.

[kanru]

Thank you, @jram0421, for opening the pull request.

@Erovia I was thinking about to put the directory under keyboard/hhkb/yang too, but I didn't want to deal with sharing code with HHKB ansi. Is it ok that keyboard/hhkb/yang is a totally new implementation?

Your other suggestions for flashing is great. I'll update them.

@drashna I opened #10674 a while ago to discuss how to structure the BLE code. If can go ahead and separate the bits to a separate PR and have discussion there.

[Erovia]

Currently everything under keyboards/hhkb are separate implementations.
Imho it still makes sense to keep them in one place, where the users would logically look for them.

[yoyostile]

I'd love to see this in master!

[kanru]

Addressed all the comments and extracted the Adafruit UART code to separate PR here #11403

[saysjonathan]

@kanru The Yang docs mention the ability to output the battery percentage as text, which is bound to Fn-E in the offical yang defaults. Is it possible to replicate that functionality in qmk?

[kanru]

@kanru The Yang docs mention the ability to output the battery percentage as text, which is bound to Fn-E in the offical yang defaults. Is it possible to replicate that functionality in qmk?

yes, it's totally possible. It's very easy to implement via extra commands or user commands. I have a local change in my keymap does just that. Let me push the commit in a bit.

[kanru]

ping?

[yoyostile]

@kanru how long does your battery last with qmk? I'm down to like 4-5 days using a 2000mAh battery.

[kanru]

@kanru how long does your battery last with qmk? I'm down to like 4-5 days using a 2000mAh battery.

About 3-4 days (using 8~9 hours per day) using a 1200mAh battery. I think it can still be optimized to double or triple the use time but I don't have a oscilloscope yet so my ability to troubleshoot is limited.

I suspect the current sleep state in qmk is not deep or long enough, after all it was for usb power saving.

[kanru]

Bump again

[noroadsleft]

Having this section as a list is preferred.

Suggested change

	Keyboard Maintainer: [Kan-Ru Chen](https://github.com/kanru)
	Hardware Supported: YANG HHKB BLE Controller
	Hardware Availability: https://kbdfans.com/products/hhkb-ble-mod-upgrade-module
	* Keyboard Maintainer: [Kan-Ru Chen](https://github.com/kanru)
	* Hardware Supported: YANG HHKB BLE Controller
	* Hardware Availability: https://kbdfans.com/products/hhkb-ble-mod-upgrade-module

[noroadsleft]

I believe this needs to be set in config.h (as #define DEBOUNCE 0) rather than here.

[drashna]

^ Correct. In the rules file, it won't actually do anything.

Though, leaving it undefined will also set it to 0.

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[stale]

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.

[floyza]

Bump, it would be nice to have this merged

[raystudioco]

Bump, has this been merged yet?
@kanru thank you for porting as QMK. I have a question, is there a Key defined for switching BT paired device could be used in keymap?

[kanru]

Bump, has this been merged yet? @kanru thank you for porting as QMK. I have a question, is there a Key defined for switching BT paired device could be used in keymap?

Extra command is defined to force a BT repair by LSHIFT + RSHIFT + S.

You can also define keybindings in your keymap.

For example:

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
    switch (keycode) {
#ifdef BLUETOOTH_ENABLE
        case KC_BTS:
            if (record->event.pressed) {
                adafruit_ble_reconnect();
            }
            return false;
#endif
        default:
            return true;
    }
}

It was limited by the Adafruit firmware on the BT module, which only supports one bonded device. So you'll need to reconnect until the correct device is selected.

---

TBH I'm not sure when this will be merged, it's been so long. Feel free to use or submit PR to my fork.

Due to the limitation of the Adafruit firmware mentioned above and wanting to have a more open hardware I have switched to a hand wired nice!nano board and custom ZMK build. I'm very happy with the new setup. Both the board and the firmware are fully open source, more power efficient (up to 15 days usage with a 1200 mAh battery), ZMK is a real RTOS and supports virtually unlimited bonded devices. I plan to also release the new setup this year.

[peepeetee]

I'd recommend reopening this PR, if you're still up to it.

Also, I've recently created a PR to collect known YDKB boards in a directory #15681 , you might want to check that out if you decide to reopen this PR