-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for MonogramCC devices #2
Comments
hi @thattommyhall thank you for the report. i'm excited to see some new hardware being tested! you should be able to set alternative device ids with the flag a few ideas to help troubleshoot:
can you include the output of |
Thanks for the swift response!
|
try modifying
|
seems to hang at
|
could you try running with |
nothing extra is printed im afraid |
oops, that should be |
I'd be happy to share a tmux session (but not tonight!) or pay for a new core module for you (ideally in the next 24h as they have a promo), email [email protected] to discuss |
you should have something in your inbox (or spam folder)! |
i'm still waiting on the new devices to be delivered. i'll post an update here once i receive them. |
quick update: still waiting on the hardware. |
update from MonogramCC: Your pre-ordered items originally scheduled to ship out in late February will now be shipping roughly two weeks later. |
finally: |
device has been delivered and i've started the reverse engineering process. unfortunately, the USB BULK protocol has changed completely from a JSON based protocol to a new binary protocol. this is great from an efficiency perspective and probably eeks extra performance out of the embedded hardware, but it means that i need to ground-up reverse engineer and build a brand new parser for the MonogramCC devices. as an example of the differences, PaletteGear devices used something like (ascii):
and the equivalent on MonogramCC is (hexbin + "ascii"):
interpretation of layouts and screen image control, two of the more challenging parts of reverse engineering the first devices also appear to have changed somewhat. i'll provide more info here as i discover. |
i haven't forgotten about this, but i have some bad news. i had reverse engineered and documented about 85% of the protocol to support Monogram CC devices in ambit (~15 hours of work) and all of it was lost when the WD BLACK drive in my laptop died. i had been lax on backups and git pushes, and ambit wasn't the only casualty. i intend to have another go at it, but it's a very tedious process and have not made time to dive in. hopefully the second time around will take less time, but i may not be able to focus on this until September time frame. |
finally diving back into this and did a marathon reverse engineering session last night. collected a bunch of usbmon captures from the new software running in a win10 virtual machine. basically made it back to where i left off before hard drive crash. after putting a good chunk of the spec together and mentally decoding the new binary format used for messages, i decided to do some internet searching and found that this is, in fact, |
a bit of a sneak peek at the new protocol decoding in action, receiving input from the MonogramCC:
|
basic LED control is now working (not yet committed/pushed): ambit-monogram-leds.mp4still to be done before pushing to master:
|
Hi @khimaros I really appreciate all the work you've put into this project! I am also experiencing the issue above, and was wondering if this work has made it into a release yet or is still a WIP? |
I tried setting it in ambit/controller
but then I get an error from pyusb
The text was updated successfully, but these errors were encountered: