chestm007/linux_thermaltake_riing

Multiple USB Controllers?

Closed this issue · 8 comments

I have a system with 5 control boxes, 16 riing plus fans, 4 rgb gpu waterblocks, an rgb reservoir (PR22-D5), a rad plus led panel, and a few of the lumi plus led strips. (24 of 25 "ports" in use total)

How do I configure this for multiple control boxes? Or do I need to run multiple daemons...?

Thanks!

Okay, got it working if anyone is curious. First pass is here: https://github.com/themikem/linux_thermaltake_riing/tree/multi-controller

Does anyone know how to run fans at "true" 100%? I'm sending the 100 command, but the fans are not turning nearly as fast as when you turn off PWM and set them to 100% in TTRGB in windows...

Sorry for not getting back sooner, I had a quick look at your code and its nice! would you mind if i merged it back in here?

re: the fan speed - Thats bizzarre, the "driver" uses the fans in fixed speed mode rather then pwm, so they "should" be running at 100% when you set them too it, your evidently handy with code so you could try removing the upper speed limit in linux_thermaltake_rgb.daemon.fan_manager.LockedSpeedController:71 and try setting a locked speed above 100% in the config

fan_controller:
  type: locked_speed
  speed: 200

and perhaps see if there is a difference between what our controllers consider 100%

I would be interested to see the results!

Sure that's fine. I'll send you a pull in a bit. I haven't had time to go back and clean this up - just spent a couple hours knocking it out so I could run some intense code under Linux without melting my rig. Could definitely use some more eyes on it.

sweet!

One thing that I know needs some attention - on my machine anyway, ctrl+c'ing the daemon at the cmd line doesn't actually kill all the threads. I have to do a manual kill on the master process. I think the catch on the keyboard interrupt is working, but there's something with the daemon and/or the dbus class that doesn't want to exit or isn't being told to exit.

Thats interesting, i only run it via systemd and i dont have hung threads, im currently about 1/2 way through a rewrite of the atrocious LightingManager stack.

Fan speed - I actually tried hard coding it to 256 just to see what would happen - no change. One interesting note - if you change that 0x01 just before the speed to 0x03, all the fans stop, but if you then send it with an 0x01 or 0x02, they all spin right back up. Good trick for silent operation.

Thats possibly because the controller doesnt actually know what to do with 0x03 as 0x02 is pwm mode and 0x01 is fixed speed - neat trick though.
I also tried setting my fan speeds above 100 last night, didnt appear to have any effect.

Do you have a detailed breakdown of the fan command message, or a usb packet capture log from wireshark or some such?

protocol.txt has a breakdown of how i understand the protocol, i unfortunately deleted/lost the wireshark packet captures i had

Hmm. Do you know how to read rpm for a certain channel? I know what the rpms are under windows. Maybe I just need to try setting 4000 RPM or something instead of 100% PWM? Should have the same effect at the control pin, I would expect...

I just figured this out

FanSpeed = namedtuple('FanSpeed', ['set_speed', 'rpm'])


class ThermaltakeFanDevice(ThermaltakeDevice):
    def set_fan_speed(self, speed: int):
        data = [PROTOCOL_SET, PROTOCOL_FAN, self.id, 0x01, int(speed)]
        self.driver.write_out(data)

    def get_fan_speed(self):
        # fan something port something speed something something
        # 51   81       1     255       100   217      6
        data = [PROTOCOL_GET, PROTOCOL_FAN, self.id]
        self.driver.write_out(data)
        id, unknown, speed, rpm_l, rpm_h = self.driver.read_in()[2:7]
        return FanSpeed(speed, (rpm_h << 8) + rpm_l)

if you drop that into devices.__init__ and import namedtuple then you can call device.get_fan_speed to get the fan speed, in testing i just hackishly threw that call into daemon._main_loop() and dumped to the log every second.

Also I just finished hacking together something similar for the Corsair Commander Pro. (I have a Corsair setup that I would also prefer not to reduce to a bubbling puddle of goo ;) Do you have any objection to having TT and Corsair support in the same code base?

I had thought about something similar, im not sure if it'd be better to combine it all into a monolithic controller or implement them as seperate controllers with some sort of communication (that might get messy FAST). I'm more or less on the fence, so to speak

also if i may, would you mind testing my new-light-modes branch against your hardware? it your existing config will work, aside from the lighting section - as i've changed the names of some of the lighting modes that will need updating.

Closing as i believe this is solved