POE Keypads

[jberry]

I know AmpliPi is designed to not need in-wall keypads, but sometimes they just make sense. In the garage with dirty hands, when you need to quickly adjust volume or mute something, etc.
And for those of us with in-wall keypads from existing systems, we're usually left with a 1gang box with an Ethernet run.
I'm thinking a PoE powered ESP32/Arduino/RaspiZero with either a touchscreen, or LED's and buttons, would be a fun open-source add-on project.
So having just backed AmpliPi w/ an addon controller (June/July won't come soon enough!), I'm going to start poking at the API and potentials.

Before I do that, I wanted to check if anyone else is already in-flight on this or not, before duplicating efforts and starting a github repo.

So, anything in flight? And/or anyone have related ideas? Maybe an AmpliPi discord channel would be a good thing to have around for q&a/dev efforts/etc?

[kjk2010]

I plan on doing this with my setup as well, but have just started researching options.
I've been leaning toward an ESP32-type setup like FreeTouchDeck, or a Raspberry Pi w/ touchscreen. I've been looking at screen sizes between 3.5 and 5 inches, as I'd also prefer to keep it near the size of a 1 gang box. I feel like the RPi option would be easier to set up, but could end up being overkill for something as simple of a keypad. My favorite idea is a ESP32, touchscreen, and 3D printed case to seamlessly integrate it in the wall.

I'm currently playing around with adding internet radio streaming functionality to the AmpliPi, but I'd like to help with a keypad design if I can.

[AmyYummy]

Wow, Wonderful ! is this a new product or invention?

[jberry]

Awesome, I figured someone else had to have been thinking about this already! I'd love any help and at least we won't duplicate efforts.

That FreeTouchDeck looks awesome, that's a good head start for ESP32. The only contender I'd say would be some of the newest Adafruit/Arduino stuff running the Cortex processors (ATSAMD21), purely if more processing power is needed.

I say we stay away from Raspi unless something ground-breaking requires it. Too complex of a system for such a simple need. We don't need a full blown, slow-to-boot, vulnerable-OS as the base for a keypad. Or that's my thought as I've thought about it more after your comment, I was on the fence to begin with and I think you hit it: overkill.

One thing missing in my head so far is how to keep the keypads up to date, without spam-querying the API...I might pull down the AmpliPi source code and see how bad it'd be to add in MQTT support at the zone/group level. That, or stick a motion-sensor on the screen/buttons, do regular API status updates, and then do an immediate API status query anytime it senses motion, like someone coming to the keypad to do something. Might be a good way to extend touchscreen-life too: motion-sensor based back-light.

I'd imagine creating a base project with the core code (API/functions), then splitting it to two overlay libraries: touchscreen, and physical keypad/led. I'm specifically after the physical-buttons for my Nebraska garage: touchscreens don't live too long in -20F temperatures, but even the big companies have this same issue. But inside the house, definitely touchscreens for the win.

I've done enough Fusion360 cad stuff with my 3d printer, I think it'd be easy enough to design a 1gang kit for either-one, even if the touchscreen was 1gang-based with a larger protruding screen bezel. And JCL makes PCB's cheap as heck anymore, so wouldn't be hard to toss together any boards needed (like keypad, or screen+motion, etc).

[jchambers2012]

As a home assistant (HA) user; there is a project to help build hardware sensors and whatnot. Since I assume a HA API/Plugin would be just down the road; HA can track the state changes and push that down to keypads while also exposing other objects light lighting. Here is a link to a touch screen https://esphome.io/components/binary_sensor/nextion.html

Also, some off-the-shelve keypads that might be used as the hard part of the hardware are all ready to go. Just a new firmware would be needed to directly interface with the API (i would recommend looking at HA Switch Plate as it designing to be installed within a High Voltage light switch plate):

• https://hackaday.io/project/163936-haswitchplate
• https://hackaday.io/project/162060-top-wall-mount-touchscreen-for-esp8266-esp32

[jberry]

I think we'd want to tie the keypads into AmpliPi itself, and not be dependent on another 3rd party system. I myself run OpenHAB and have zero plans to jump to HA, and I'm sure you're the opposite: Run HA and wouldn't switch to OpenHAB. And there's probably others who run neither (Vera, HomeSeer, Ocelot, Creston, etc, etc, etc).

At the end of the day, HA (and/or OpenHAB and/or others) has to get the updates itself somehow; whether that's spam-query the API, have hooks into the core AmpliPi code itself, or other. So there's not much reason I can see to be dependent on another system if we just hook in the same way ourselves to the core.

I just saw #73 is talking about implementing SSE, so I think that's the answer here: ESP32 subscribing via SSE for updates, and sending commands via API calls. I'd imagine the 3rd-party-integrations will be using SSE as well once it's all said-and-done.

However I think your hackaday links do solidify the answer in my head: ESP32 as the core unless we hit limits.

The HA Switch Plate would be a good candidate for another over-the-top library. My use-case has zero mains-powers so it'd be a no-go for me, I'm specifically needing something that implements a replacement for anyone who has a prior-whole-house-system and has ethernet ran to the gang boxes for keypads (single-gang boxes by themselves, no power nearby/in the box). But, not everyone already has that either, and that HASwitchPlate project is awesome for $70. I might just have to use that when I finish my basement...if it can be taught to use SSE instead of/alongside MQTT, since it sounds like SSE is the direction AmpliPi is going.

So, ESP32 core, with a base AmpliPi library implementing the SSE/API calls; then front-end libraries for whatever interface people implement: FreeTouchDeck, HASwitchPlate,custom-keypad, etc.

[kjk2010]

@jberry With your current ethernet runs, are you thinking about powering these keypads via POE, or using the ethernet runs similar to how other whole-home audio systems use them (serial connection with DIP switches to select device IDs I think)? If it's POE, there are some ESP32-POE boards out there that would allow the rest of the keypad project to be nearly the same, just with this POE version of the ESP32.
I'm building a house right now and trying to decide if I run ethernet to each keyboard location or not. I'd rather rely on ethernet over Wifi for the keypads if possible.

The HASwitchPlate is exactly when I was envisioning for a touchscreen keypad. I agree with @jberry that it would be nice to have these directly integrated with AmpliPi, but I could also see where I would also want some keypads to integrate with HA. The HASwitchPlate has the source code, BOM, PCB, etc. all available, we could expand on that project to let people choose AmpliPi integration, HA, or both. For the devices themselves, we could have designs for touchscreen or with physical buttons, and they could either be POE or mains powered, depending on which ESP board is used.

[jberry]

My idea is POE-powered network-device'd IP-addressed keypads, taking advantage of the API and some sort of publish/subscribe system to receive updates. This is what would retrofit into an existing other-vendor whole-house system setup; Niles, Nuvo, Russound, etc all use some-form of ethernet-cable-based keypads. Definitely not serial/CANBUS keypads like some of them though.

So I think the common-point between us is: an ESP32 library to integrate with AmpliPi. Maybe that's a good first-target, and from there other projects will fork. Dedicated AmpliPi drop-in keypads for retrofits, and then non-AmpliPi-specific projects like a all-in-one HASwitchPlate that just happens to know how to control AmpliPi as well.

As for building your house, my suggestion is ethernet is cheap: Run it anyways (Cat6 minimum nowadays), and if you never use it you'll be out not-a-lot-of-money and some time; but if down the road you wish you HAD run it, that $300+time will look like nothing instead of trying to fish-tape between floors to run wire and then hitting a fire-block 2x4 and screaming bloody murder 💀. I built my house ~12 years ago, and I wish I had ran MORE ethernet. I've added ~20 drops over the years, luckily my basement is still unfinished: 2 to every TV (one for the TV, one for the streaming device), 1 in every corner of my home office, 1 for a POE Ubiquiti router mounted on my ceiling, a few for gaming devices in the corner of the living room, POE security cameras on the eve's of the house, etc.

Wi-Fi is convenient, but ethernet is fast and dependable. Plus, PoE is low-voltage, no electricians involved!

[gorski123]

Hey Guys,

This is friggin awesome. Thanks for taking the initiative on this and finding some really cool off the shelf controls. Us here at MicroNova have had a few talks about adding these as well and we basically came to the same conclusions as you guys did - Pi Zero or ESP32 both seem to fit the bill well. We had also floated the idea of perhaps using an e-ink display and attempting to make a wireless battery powered keypad. My plan is at some point to design and build some keypads that we can offer for sale along with AmpliPi but I think in the short term something off the shelf or home-built could work well. I think talking to the box through the REST API is a nice solution. It cuts down on the amount of home run drops you need to add. The software is already designed to handle control from multiple sources over the API so we would be less likely to run into problems. For example, if you change the volume on the local keypad, the app would properly show the new volume level and vice-versa.

With that being said, I did stub out a header for a UART on the latest hardware rev of the control board, so if someone did want to go old school and do a serial interface to the keypads, the capability is there. For the network keypads, we would like to support you guys however we can. I think @linknum23 had opened an issue to add server sent events. If you need anything else from us to help this effort along let me know! So so awesome :)

Jason

[sanders5x]

I like where this is going. I would like some form of local control, a phone might not always be covenant. I like the idea of conforming to a standard Decora Wall plate. Something with different colors would be nice for blending in: White, Light Almond, Ivory, Black.

[kjk2010]

I've been working on an initial prototype and putting together some code for a touchscreen keypad. I'm using a 2.8" ILI9341 screen off Amazon with an ESP32. I have some Olimex ESP32-POEs ordered as well as a 120v AC to 5v DC power adapter to test both in-wall POE and WiFi versions.

I'd be glad to share the rough code if anyone is interested. It has a little ways left to go, but can currently set and mute the volume of a zone, and automatically update album art/logo and metadata on screen. The next step is to allow selection of streams, as well as play/pause, skip, and other buttons available on the current AmpliPi web interface.

[jberry]

If you wouldn't mind creating a Github repo, that'd be awesome! I have a Nextion 2.4" screen on the way, along with (probably) the same Olimex PoE stick, as well as a 16button array to start messing with before creating a button PCB.

[kjk2010]

Here's the repo: https://github.com/kjk2010/AmpliPi-Touchscreen-Keypad
Hopefully the code isn't completely worthless :)

Assuming the POE boards fit well, it will be much nicer to have everything powered over the network cable versus having to deal with powering the keypad with mains power.

[kjk2010]

I've been working with the ESP32-PoE board and have put together a new repo for this board which utilizes the ethernet connection instead of WiFi: https://github.com/kjk2010/AmpliPi-POE-Touchscreen-Keypad

Later this week I plan on prototyping a simple board that connects the ESP32-PoE's UEXT port to the touchscreen, and will upload those details to the repo when it's working.

My end goal is to make the project as easy as:

1. Flash the ESP32-PoE with the pre-compiled firmware
2. Plug the ESP32-PoE and touchscreen into the connector board
3. Put everything into the 3D printed mounting box and plug in ethernet cable

[linknum23]

At Micronova we have a ESP32-POE board and a similar touch screen. Looking forward to trying this out after our first release.

[linknum23]

Finally got around to testing this today now that we are adding in the album art changes, looking good!

[kjk2010]

Getting closer to a first release of the ESP32 firmware. Have some PCBs on order and worked on making the GUI compatible with multiple screen sizes.

One item to note to the AmpliPi guys is that the keypad must get its album art as JPG files of a certain dimension. Currently, I've patched my app.py file on my dev Pi to add a '/api/streams/image/int:sid' route to the API, and some code to get the album art and convert it to JPG when the keypad requests it.
I plan on submitting a PR for this code patch once I test album art with streams other than Internet Radio. Hopefully this PR will be worth adding to the main project so the few of us with keypads won't have to manually patch our AmpliPis.

[kjk2010]

I think that's a valid way to handle this situation. It would also be usable for any mobile apps and other types of clients.
iTunes does this in their API for example (https://developer.apple.com/library/archive/documentation/AudioVideo/Conceptual/iTuneSearchAPI/SearchExamples.html):
artworkUrl30, artworkUrl60, artworkUrl100

The other option I can think of is for the client to request a specific size, and AmpliPi dynamically creates and caches the image at that size. This would potentially lower the computing time needed, as it would only need to create the images if a client is requesting them, and only at the size being requested. The downside is it might be slower for the initial request, but from my testing, that amount of time is less than 1 second.

[linknum23]

Thinking about this a little further I really like the flexibility of dynamic generation of images at a specific size. Going that route we could add a dumb version at first and then later if we felt like it make a smarter version that "precached" anticipated requests. I would hate to waste CPU on something that only 1% of clients used in the field.

I think this line of thinking fully justifies adding an additional API endpoint.

[rickballard]

Is anyone willing to make and sell some prototype keypads for decora wall-receptacles that have cat5+ back to the Amplipi? If so, please allow me to take 4 as I am replacing a Russound CA4.4. Thanks!

[gorski123]

Hey @rickballard This is very high on our priority list. Once we get over the initial backlog of AmpliPi orders we plan to start working on this. Stay tuned for more updates.

[rickballard]

Can the keypads have microphones? That way you are more likely to get a partnership or acquisition offer from Google, as WHA-systems become audiophile Google Home boxes. Although, speakers (especially in ceiling or facing users) can act as very sensitive microphones if you bridge each one with a $1-clip-on-heterodyne (invented in Denver, by a retired guy I know). That way, the AmpliPi could perhaps add Google Assistant functionality that has beter voice-detection accuracy than Google's own Home product line. Please email me if you want that retired guy's contact info -- he's so kind, he will likely be honored to give you, or open-source, his application.

[rickballard]

Would it be appropriate for me to donate to whomever making prototypes, to cover expenses? Attached is a roughin for a typical non-smart POE keypad, showing buttons for source, volume, backlight, store and power.
A small touchscreen would be more flexible.

[rickballard]

Excellent work! You are a Genius Angel from the Hackiverse. Do you have any plans to make a v2, perhaps with better viewing angles and responsiveness? If so, would you like me to order the components, perchance for delivery to your temporal mortal vessel on this side of the Hackiverse, Angel Sir...?

[kjkoning]

Thanks for the compliment :). I'm already prepping version 2 and I have a 4.3" capacitive touch screen on it's way. The screen uses a parallel interface instead of SPI, so it should be more responsive along with the capacitive touch. While waiting for the screen I'm making some adjustments to the UI to make it easier to use. It's funny how a touch screen UI is different if it's on a wall versus in your hand.

[rickballard]

How goes version 2 ..?

[rickballard]

@kjkoning Did version 2 of the keypad work out? Is it something others could implement too?

[rickballard]

Awesome wall panel, great work. Thanks. Although, it seems that my Google Mini smart-speaker has yet to learn the word AmpliPi, despite my best efforts to teach it.

[rickballard]

The wall controller is excellent, and getting better with each new software download. Thanks for your work on this.

[Juggler00]

I would love a wall controller, but really want to use PoE rather than mains power + WiFi. Any chance we'll see an official product like this?

[linknum23]

We don't have any plans to make a POE version right now but it is something we will definitely consider in the future.

…

On Sun, Jul 31, 2022, 08:49 Juggler00 ***@***.***> wrote: I would love a wall controller, but really want to use PoE rather than mains power + WiFi. Any chance we'll see an official product like this? — Reply to this email directly, view it on GitHub <#77 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEZPO6TC24AAHKAFOWI2LLVWZY4TANCNFSM4YLYVCIQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>