There are a few clients. I"ve written a new one every year or so, if not less frequently.
The latest client, which I used to take these screen shots, are in the new-client/ repository.
The client is written in React JS. The design is for 1024x768 fixed size screen. There is a separate (in progress) complete display for Phone and for tablet in portrait mode (in portrait mode, it's a dedicated theater remote).
Dude!
This is very cool.
RoboDomo supports both Hubitat (preferred) and SmartThings hubs. Both hubs can connect to thousands of kinds of devices, both Z Wave and Zigbee.
Looking forward to hooking this up to my hub for some of the integrations you have covered that I haven't found here.
This is REALLY impressive. 
I bought a cheap Celeron based micro PC and put 4G of RAM in it and a 60GB SSD. It cost me < $150US. The thing runs Arch Linux (any linux will do) with Docker. All the Docker containers run on it at the same time and it uses far less than 5% of the CPU. The machine now has 465 days uptime (I should do a software update on it at some point, but that's how non-stop the back end has been).
I have the Hubitat<->MQTT microservice and the triggers microservice running on another machine, an I7 NUC, which has the fastest single core benchmark speed of the computers I have (including the Xeon iMac Pro). The MQTT broker is also running on the NUC. I did this for the short term to assure that it isn't my code that is causing any delays when running or the MQTT broker is not a bottleneck.
Macros are just a list of MQTT topics/messages. Here's an example macro. The macros are defined in a Macros.js file. When you edit the file, the macros-microservice automatically restarts and reloads the new/updated file.
The macros can call other macros (like subroutines). You can see that in the example above.
As you can see, the good night macro turns off a lot of things, several having nothing to do with Hubitat (Z Wave or Zigbee or whatever). Before I added macros, I woke up more than one time to find I forgot to turn off the spa (I had to turn it off by going into the master bedroom and using the physical panel on the wall).
I'll do another post about triggers.
triggers-microservice is what really puts the smarts in smart home. It's basically a rule engine kind of thing, but instead of point and click and some (potentially) limited language for defining rules, you have all the power and flexibility of the JavaScript language.
I have a rule that watches the hot tub state. When it goes in, the rule watches the temperature and when it hits 90, it announces the spa has reached 90 degrees. It's desert where I live, and the spa hits 90 on its own (from the heat/sun) in the summer, so a simple "when temp is 90, announce" kind of rule is insufficient.
I have another rule that watches a motion sensor in the master bathroom. When motion is detected, it sets the dimmer to 99% during the daytime, but 5% overnight. This rule is fairly simple, and there's likely a way to do it with Hubitat proper. Although if the motion sensor is on the Samsung hub and the dimmer on the Hubitat one, then my rule works.
For the fart fans in the bathrooms, you don't have to manually turn them off. They turn off after 15 minutes (you can change the timeout). But they don't turn off if you have a light on, so you can force the fan to run while you're doing something like painting or cleaning.
Similarly, the dimmers in the bathrooms turn off after 15 minutes, but not if you have another light on.
The RGB lighting under the cabinets in the kitchen require the RGB values to be set when turned on. There's a button rule that does this. When cabinet switch turned on, send the MQTT to set the RGB values.
Outdoor lighting is turned on at sunset and off at sunrise. There used to be a timer out there, but because the sun rises and sets at different times every day, you would have to adjust the timer every so often. Using sunset/sunrise is perfect every day.
If the garage door is up/open for 15 minutes, there's a rule that sends me emails, text messages, announces out load, etc., that the door is open (every so often). If I forget to close it for some reason, I get to know it's open.
There are triggers to announce certain events, like when a lock is unlocked or locked, or at sunrise/sunset, garage door open/closed, person arrives, etc.
There are triggers to deal with virtual devices. For example, I created virtual switches in the Hubitat UI for the TV in my office, the spa, the waterfall for the pool, the jets for the spa, and so on. When the spa is on, the trigger sets the virtual switch on. When the spa is off, the virtual switch is set to off. If you manipulate the virtual switch via the Hubitat UI (or RoboDomo UI), the spa goes on or off. If you use the pool control WWW site (it's a local http server) or the on wall pad, the switch gets set proper.
The real reason I did the virtual devices is that it's a clever and free way to add things for Alexa, Google Home, and Siri (via Homebridge) to control. I can do things like, "hey Siri, turn on the spa" or "hey Siri, turn on the Office TV".
The rule for the Office TV isn't all that simple. It deals with the Denon AVR, the AVR and TV inputs, the AVR and TV power status. Turning on the TV really means, turn on the TV, turn on the AVR, set TV input to HDMI1, set AVR input to TV Audio, etc.
There is no limit to what you can do in JavaScript as far as rules go. You can get all the events going on via MQTT that you care about, and you can send MQTT messages to control things.
My current project involves arrival detection. I want to reliably open the garage door when one of the two cars arrives, and open the golf cart door when the golf cart arrives. And to lock the locks in the home when nobody is home.
Other rules are kind of obvious. Like disable A/C if a window or door is open (or refuse to turn it on). Hubitat might control and monitor the door and window sensors, but the A/C is not controlled at all by Hubitat (it has no clue about it).
DNS and networking is another topic I'd like to offer some suggestions about.
I have a $50 ubiquiti EdgeRouter X (ERX) as my router. I run dnsmasq on it to do DHCP (assign IP addresses) and DNS name lookups. The DHCP is configured to assign the ERX as the DNS server to everything that asks for an IP using DHCP.
A trivial trick that I use is to use a net mask of 255.255.0.0. Normally, the net mask is 255.255.255.0.
Without my trick, you are limited to 254 IP addresses for all your networked devices, and that pool of addresses includes dynamic IP allocation when some device joins your network that you don't have a DHCP entry configured (like a visitor's phone).
With the trick, you get all of 192.168.whatever.whatever, which is a LOT of IP addresses. I use 192.168.0.whatever for computers. I use 192.168.1.whatever for the router(s) and switches. I use 192.168.2.whatever for mobile devices (phones, tablets, watches, whatever), 192.168.3.whatever for home automation (Alexa devices, Smartthings hub, Hubitat hub, the pool control, the nest protects, and the iComfort router. I assign 192.168.4.whatever for home entertainment devices (TiVos, Apple TVs, Harmony Hubs, Denon AVRs,e tc. I assign 192.168.5.whatever for scanners and printers.
My HOA fees include a subscription for Spectrum internet and TV. But we have fiber optic here, too, and gigabit ethernet for a good price from Frontier Communications. So my home is dual homed. I configured the router to route all traffic originating from 192.168.100.whatever to the Spectrum router/internet. Everything else uses the gigabit line. The Spectrum TV app on Roku devices (and others) give you all your subscribed channels if you are using their Internet/routers. Putting the Rokus on the 192.168.100.whatever network achieves this (uses Spectrum routers). The Spectrum TV app otherwise gives you a limited number of channels.
DHCP in dnsmasq is done in a config file on the router. You add a line like:
dhcp-host=70:hidden:81:ed:85:hidden,192.168.100.16 # appletv-mbr
And whenever the Apple TV in the master bedroom requests an IP via DHCP, it is ALWAYS assigned 192.68.100.16. The DHCP protocol involves sending the requesting system's MAC address. The line above causes dnsmasq to match the 70:hidden:81:ed:85:hidden MAC address for the IP assignment.
DNS lookup is handled by dnsmasq, too. This is really simple to set up, as it just reads the /etc/hosts file (on the router). So I edited the /etc/hosts to include a line:
192.168.100.16 appletv-mbr
Now I can address/ping/connect to that Apple TV using the name "appletv-mbr".
I took the time to add almost every device in my home to the DHCP configuration file. I can ping a phone by name because the DNS lookup always returns the same IP, the IP that is always assigned to the phone. I can control the TVs by name for the same reasons. And so on.
The DHCP configuration and netmask can be set up in most consumer routers. I see \oth the Spectrum and FiOS (gigabit) routers have WWW pages to configure these.
If you don't set up DHCP like I did, most devices advertise a name and get assigned a random/dynamic IP. You can address those devices by name as if you did my DHCP kind of configuration. The issue is not all devices will advertise a name like this. It's going to be hit or miss. The Apple TVs definitely do this, for example.
As far as the local control of the hub, RoboDomo's macros would run slower if they had to control each device (thing, switch, etc.) via an HTTP request to the cloud.
Plus, the more cloud activity you do, the more at risk you are to hackers, no matter what the cloud providers say. Hey, the government just got hacked, and they literally have $trillions to spend to avoid these things.
RoboDomo started out as a simple thing. I wanted to turn on and adjust both the A/C and the ceiling fan from the couch. Manually, I'd have to get up and go into the hallway to adjust the A/C and that's also where the fan control is.
Once I got a GE Fan control installed (and a ST hub), I found myself switching between three apps on my phone: ST, Nest, and Logitech.
To date, none of these hubs is one hub to rule them all, to control all the things. RoboDomo is one app that I don't need to switch between any of the others to do what I want.
Google's services were down early in the AM here in the US. People were saying their lights don't work because the Google Home wasn't able to connect to the cloud. I wonder what kind of switches they use that they can't use the physical switch on the wall to manually turn on the lights.
Another reason to not want to rely on cloud APIs.
It's surprising but there are some people that replace the wall switches with inline modules. No physical switch anymore. It's kinda crazy to me. I've seen this in commercial or larger installs with panel controlled lighting but they are NOT cloud dependent and there's still a switch at the panel to use.
It's just a bad idea to depend on any technology for any critical functionality. There must always be a manual override or backup. Depending on "cloud" is a major mistake by anyone.
Many inline modules permit external control with a physical switch. I used to have Aeotec's that permitted it. Now I'm all Caseta.
Yes. My Point was that "some" people install just the inline without any switch. Which I think is a really bad idea.
I'm interested in playing with RoboDomo but....,
I'm not programming savvy and don't see a clear why to get started. Always hated GitHub documentation as to me it seems to make simple things incredibly complex by it's very nature of organizing/displaying of information.
Wish there was a clear "How to document" to help more simple minded people (like me) to get their feet wet with cool things like this. But maybe it's intended more for the adventurous programmers out there, and not ordinary folks. Kinda of members only club for Mensa groupies?
I have an older Asus Chromebox that's itching for a Linux install. Maybe it could serve as a RoboDomo server, but it may all be over my head.
I have 4 ceiling fans with RF remotes and I hardwired load to line and put Eria Dimmers in the gangbox. HOWEVER, I still have the native remotes in drawers in case something goes wrong. I had to hide them because when I had some issues with Picos & Bond when 1st doing this, the "better half" kept reaching for the native one. To your point, I have backup. 
Your stock just keeps going up.
Wow, this topic is really off topic!
RoboDomo is definitely an engineer's thing. It's custom to MY preferences and needs. It's open source and freely available to anyone who wants to hack on it to suit their needs. It's not mean to be a consumer thing.
I'll post about inquiries I've had about it in a separate post.
I recently had to replace the A/C unit on my home. The old one was almost 20 years old. As I was getting bids, I showed RoboDomo to the sales guys and they loved it.
I spoke with the owner of one of the local A/C companies and he wanted to invest in it, sell it, and have his installers install it in homes.
Having been involved in IoT for a few years now, my assessment is that it's really a hacker's thing still. ST and Hubitat and the others make it easier, but if you can't edit YAML files or grok Groovy, Python, JavaScript, and know your way around GitHub and IDEs and package installations, it's going to be rough.
How custom is RoboDomo for my needs? At night, we watch an hour of TV in bed, then go to sleep while leaving the TV on. When the hour is up, I was using the universal remote (or the Theater screen on RoboDomo) to bump up the center volume on the Denon AVR and lower the regular volume. I have to hit the "volume up" button like 24 times to get it to max. I added a button to the UI to do it all with a tap on the screen. Do YOU need it? Probably not.
But the client is pretty simple React JS code. If you don't like how a tile on the screen works, it's not very much work (or hard) to alter the behavior. Like...
I had my wife and my presence on the Clock tile, and then created a dedicated presence tile to show this information. Maybe you don't want a presence tile at all - you can decide not to have one on your dashboard(s) at all.
As far as dashboards go, the Hubitat one (in the browser, app) is good, but not something I want to use 24/7. No offense to the Hubitat guys, but they have a lot of more important things to focus on, IMO, like adding more device support, fixing bugs, and updating features/apps.
The best dashboard (other than RoboDomo) that I have used is the HomeKit one in the Apple Home app for desktop and mobile devices. They don't let you have tiles in multiple rooms (like presence sensor in every room, they only allow in one). But they do allow you to drag and drop the tiles into the order and rooms as you want.
Compare that to RoboDomo, you have to edit a JavaScript (JSON like) Object to order your tiles. Hubitat, you have to bring up a joy stick looking UI to move the tile left, right, up and down (rows, columns) until it's to your liking. Drag and drop is something web apps have been doing for years...
RoboDomo doesn't compete with Hubitat, as I've said before. I'm not here to leach Hubitat customers, only to make their homes using Hubitat "better" (in the eye of the beholder). If I ever did a deal with an A/C company, we'd be buying at least one Hubitat hub per home we sell to.
Download the Hubitat app
