It’s more or less a consumer version of their RA2 system, which is its own protocol. The gateway interacts with the whole system using commands issued over telnet though, so you actually have a command line for operating and configuring it. It integrates with a bunch of closed systems, and it integrates right into Home Assistant with a first-party HA integration.

It’s not like you can inspect the source code for their firmware push up pull requests on GitHub, so I’m this aspect, yes, it is proprietary. However, with tools like Home Assistant, which is something you probably should be using, this becomes much less of a concern, in my opinion. It’s robust, high-quality, and is commonplace, so you can get bits and pieces at Home Depot.

If you’re interested in something that will work with mesh networks and you aren’t interested in running software like Home Assistant, you should look for Z-Wave or Zigbee hardware. Read reviews though; I’ve had a lot of mixed experiences with hardware, even from “trusted” vendors.

Try a Lutron Caseta dimmer with a Pico remote. They work together as-is without a gateway, and the Gateway Pro will join it to something like Home Assistant in the future. Or you can simply use the Caseta app.

Imagine your “code” as English sentences. If it is hard to read, you might rephrase it. If something is getting long and drawn out, use paragraphs (methods and functions). At the end of the day, the easier it is to read, the better, unless there’s a performance cost that’s worthy of considering.

Like the top-level comment suggests, you should comment your methods. I would go one step further and use a standard comment format. I like Ruby, so immediately, I think YARDoc. With a YARDoc comment, you define what it does, the parameter types and descriptions, what it returns, possible exceptions that could be returned, etc.

Even better, by using standardized comments, not only does this make it easier to read by you and others, but most of the time, you get documentation rendered for free. For example, here is a library I wrote:

• https://github.com/synthead/timex_datalink_client

And here is the automatically-generated HTML documentation:

• https://www.rubydoc.info/gems/timex_datalink_client/0.12.3

More specifically, here’s some YARDoc for a method:

• https://github.com/synthead/timex_datalink_client/blob/263bffa8a71a0af792c46bea2ae69ab2a015f670/lib/timex_datalink_client/protocol_3/time.rb#L38-L46

And here is the generated documentation from this comment:

• https://www.rubydoc.info/gems/timex_datalink_client/0.12.3/TimexDatalinkClient/Protocol3/Time#initialize-instance_method

This style of auto-generated documentation is available for pretty much all mature languages, and I highly recommend that you hit the ground running with them 👍

Why Apple?

To people that really spend time in code, this banter is meaningless.

You don’t enjoy a plugin like gutentags? You’re missing out. Don’t let your principles get in the way of your productivity.

Probably whitespace.

It seems the world has shifted towards architectures and tooling that does not allow dynamic linking or makes it harder.

In what context? In Linux, dynamic links have always been a steady thing.

I love that :) Try Pry, too!

You might enjoy Ruby

Yup. Just add a comment that says “add tests for this” on lines of code that needs it in the review. If your dev ends up taking a couple of weeks to finish it, so be it.