CoretechR
Support for OMOTE Hub
OMOTE Hub
The goal of this PR is to send commands to a hub instead of sending IR commands directly from the remote.
The hub consumes messages and is responsible for communicating with the devices. Currently, the OMOTE hub is written in Python and can be run on any linux machine (in my case a Raspberry Pi 4).
Hub transports
Communication between the remote and the hub follows a pub/sub pattern. This allows us to easily swap transports on both the remote and the hub depending on user preference, hardware availability, and use-case.
-
ESP-NOW
- Pros
- faster boot times (~450ms faster wake compared to MQTT over Wi-Fi)
- long range (up-to 185 meters line-of-sight, compared to 80 meters Wi-Fi and only 15 meters BLE)
- low latency (135% faster than Wi-Fi and 350% faster than BLE when transferring a payload of 50 bytes)
- simple, no extra infrastructure required
- Cons
- max payload size of 250 bytes
- power consumption appears to be about the same as Wi-Fi
- Pros
-
MQTT over Wi-Fi
- Pros
- very flexible
- virtually no limit on payload size
- Cons
- slower boot time
- higher latency compared to ESP-NOW
- shorter range
- MQTT requires an additional layer of infrastructure / maintenance / complexity
- MQTT may drop messages unless QOS is changed
- Pros
Contract between hub and remote
The remote emits RemoteEvent's, the hub subscribes to these events. The data contract is simple yet expressive (remember we have a 250 byte payload cap if using ESP-NOW).
{
"device": "APPLE_TV",
"command": "UP",
"type": "SHORT",
"data": [] // optional additional data
}
Currently the hub doesn't communicate 2-way, though this is something I'd like to enable soon. For example, I'd love to display the audio level from an AVR or "What's Playing" information on the remote.
The hub will likely emit something like HubFeedbackEvent's.
{
"device": "APPLE_TV",
"data": ?
}
The Hub
The hub primarily supports RS-232 and IP Control (HTTP) transports for different devices. I'd like to explore IR emitters and Bluetooth in the near future. I've found controlling IR emitters from Python to be challenging in my tests thus far and might need help.
I'll be opening a separate PR shortly which adds a new directory containing the hub software with more details on functionality.
Thanks @Stuckya for this PR. I already started review and added some comments. More comments will follow the next days. Adding more comments does not mean I don't appreciate this PR. It simply means I need more than one day for reviewing.
Some more thoughts:
- could you please already start thinking about on how to integrate this into the wiki. Probably should be somewhere here Could you provide some markup for the wiki? Unfortunately cannot be provided as PR
- code for the hub itself should maybe provided in a completely separate repo, since the underlying technology is probably completely different. What do you think? I have seen this concept in other projects, where e.g. there were separate repos for the backend server, the web frontend, the Android app, ...
- could you please already start thinking about on how to integrate this into the wiki. Probably should be somewhere here Could you provide some markup for the wiki? Unfortunately cannot be provided as PR
Yes, I have some rough notes but need to sit down and spend time on documentation. Should I share the markdown over Discord?
- code for the hub itself should maybe provided in a completely separate repo, since the underlying technology is probably completely different. What do you think?
I don't have a super strong opinion here and we might want to consult @CoretechR too. I've worked professionally in some large monorepos with multiple languages without problem. I could easily see the hub becoming another top-level directory. Example:
OMOTE/
├── CAD/
├── PCB/
├── remote/
├── hub/
└── images/
I like the monorepo approach because it is easier for the user. They don't have to worry about cloning multiple repos to get started.
That said, I do think multiple repos can work well if there is a Github "Organization". This also helps with managing access for multiple core-contributors.
Which would look something more like:
https://github.com/OMOTE/omote-remote
https://github.com/OMOTE/omote-hub
Yes, I have some rough notes but need to sit down and spend time on documentation. Should I share the markdown over Discord?
What about sharing it here? Everything at one single place.
I don't have a super strong opinion here and we might want to consult @CoretechR too. I've worked professionally in some large monorepos with multiple languages without problem.
The only concern I have that you will use completely different technologies for the different directories. For a professional, it is no problem having Java, Angular, docker-compose and whatever all in the same repo. But here, some people already struggle using only PlatformIO for compiling and uploading the firmware to the ESP32.
I haven't seen the hub code until now and how it works, maybe we can discuss this later. I also wouldn't merge this PR before we also integrated or linked in some way the hub.
That said, I do think multiple repos can work well if there is a Github "Organization". This also helps with managing access for multiple core-contributors.
That looks interesting. @CoretechR ?
@KlausMu I have not looked into it in detail, but a GitHub organization seems like a good fit for open source projects like this. We could also split the project into hardware and software repos. But all of that should be thought through well.
Did you see that the PR still does not compile?
Compiling .pio/build/esp32-s3-Rev5andHigher/src/applicationInternal/keys.cpp.o
In file included from src/applicationInternal/hardware/arduinoLayer.h:7,
from src/applicationInternal/omote_log.h:26,
from src/applicationInternal/hub/hubManager.cpp:3:
/home/klaus/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:155:6: error: conflicting declaration of C function 'long int random(long int)'
long random(long);
^~~~~~
Did you see that the PR still does not compile?
Compiling .pio/build/esp32-s3-Rev5andHigher/src/applicationInternal/keys.cpp.o In file included from src/applicationInternal/hardware/arduinoLayer.h:7, from src/applicationInternal/omote_log.h:26, from src/applicationInternal/hub/hubManager.cpp:3: /home/klaus/.platformio/packages/framework-arduinoespressif32/cores/esp32/Arduino.h:155:6: error: conflicting declaration of C function 'long int random(long int)' long random(long); ^~~~~~
@KlausMu, fixed. Branch is up-to-date and all builds passing.
What do you think about starting another repository in the OMOTE-Community organization for me to commit and push the hub code?
@Stuckya thanks for the updated PR. Here are some thoughts about adding the hub code:
- what I am missing (or I can't find it) is an explanation and documentation about the hub. Who might need it, how does it integrate with other devices and so on. I would expect an short overview so that users could decide if the hub is something they need or not
- the code changes in the PR are quite big - 38 files changes. Some changes are definitely not needed by this functional change, e.g. most changes in the devices. I would prefer a PR with the bare minimum for the hub support
- Generally spoken, I am not sure if these big changes should go into the main firmware repo. Currently I see the hub only as an edge case. But I might be wrong. If these changes were merged into the main repo, they would have to be maintained by someone.
- I guess there is somewhere a different repo containing the code for the hub itself. Your proposal is to move that repo into the OMOTE-Community organization, right? Can I see this repo somewhere? Is there any documentation?