do you mean that GPIOX (as in python code) is controlling the GPIOX (as shown on dock)?
I mean the electrical traces seem to be identical so where the GPIO pins are listed in the 2 dock they are actually still on the 1 dock. Just the names have changed. Basically I did not have to change the dock because I could still use the same GPIO pins as if it was a 2 dock but taking into account the gotcha of using GPIO pins 1 6 7 8 and 45 as per the annotated pinout otherwise the Omega might not boot.
Handy. The hardware is built now and works fine just need to concentrate on the software.
While let's encrypt is great when compared to not having anything.
There are conveniences ~$150 per year buys you with an okay wildcard certificate. Certificates being valid for a span of years... Free revocation and reissue all day every day (versus a few times in a week). ...wild card subdomain support, you don't need a new cert if you roll out a new host on newhost.domain.com . Tech support tickets.
The conveniences and stability a paid SSL solution provides are likely more attractive to onion.io than saving $150. What is time worth? You have more of it if you are not dicking around with a certificate with more points of failure-- I know that. And I say that as a fan and supporter of Let's Encrypt. They are doing great things over there and have no reservations against someone using a Let's Encrypt cert-- when it makes sense to.
A thought I just had. Not best practice I know but suppose I wire up the common pin to the switches to 3.3v and had the GPIO pin default HIGH and when the button is pressed it would go LOW triggering an event. Is there any real reason I could not use 3.3V on these switches or a rotary encoder?
If you look at the topology of the Adafruit design, the power to run 5v loads has to come from first being regulated down to a plausible battery voltage, and then boosted back up. That particular board is made with components that try to support a lot of current through that path, and warns that the upstream supply needs to be quite capable to match what the board can do.
But that kind of regulate and re-boots topology, if done with lower rated components, could easily explain the kind of issues seen here, in that it can impose a bottleneck on how much power can get from the USB input jack to the USB output one. We still don't know what is on the powerdock and how it is configured, but it's not hard to imagine limitations there.
Yeah.. I figured it was being put to the back burner but really this is starting to get very frustrating. Standard packages like tinc are available in OpenWRT and so it really should be relatively trivial to compile against the 'Onion' version of the OpenWRT tree. Hell even just putting that source up as a git hub would be enough for people to be able to build packages against the Onion which fit seamlessly into opkg.
Is there a list of what 'customisations' Onion has done to OpenWRT so maybe we can patch an official build with and build from there?