@NWT.Stuff
Great work Kevin, and congrats with a successful v0!
You also mentioned a bug ‘preset 10 not working’. What kind of preset is this?
Which output device?
I think we discussed at an earlier stage to keep the ‘end product’ a clean product, with only one or two LED’s (power/battery status and wireless connection status). So my idea would be to still go that way. E.g. an Arylic Mini would do.
What do you think?
Web server
Totally fine with me.
@KolfMAKER Thanks for the feedback.
Yes I will crack on with simple LED’s
These are 10 SOURCE PRESETS on the 4STREAM APP - number 1 to 10. I just need to manage a 1 or 2 digit string. 1-9 work fine. 10 is not currently working. It should be straightforward 
Kevin
While I don’t have the jog wheel available on hand, I decided to start writing some code anyway while I wait for mine to arrive!
Using some parts laying around, I soldered up a beautiful button board for an ESP32, and wrote the ArylicHTTP library for interfacing an ESP32 with Arylic devices via the HTTP API.
Using the previously mentioned library, I build a small firmware package for the ESP32 which will grab button presses and interact with the API accordingly. I will need to make some modifications to work with the jog wheel once that arrives.
There are some improvements to be made for sure, currently the device supports only 5 functions:
The next two feature to work on are WiFi provisioning, and better volume control - Using the getPlayerStatus call I would like to fetch the existing volume and modify that vs setting an arbitrary level.
The firmware was designed to, on button press, wake and connect to WiFi; once the WiFi connection has been established, button presses will preform the above actions with minimal latency. After a period of inactivity, 15 seconds, the device will go into a low-power deep sleep mode to preserve battery power.
Some spare parts, an ESP32, and LiPos I had laying around, and now I’ve got myself v1 of an Arylic remote!
I am thinking a single RGB LED can accomplish all of these things, here is going to be the plan for my firmware:
Blue flashing
– Unconfigured / Setup Mode
Purple flashing
– Connecting to WiFi
Purple solid
– Connected to WiFi
Red
– Number of flashes indicate error code
— Error connecting to WiFi
— Error when making API call
— Low battery
@mclarkdev Matt.
It seems a lot more professional software than I have managed as it’s certainly not my day job 
I’ll update the functional specification and e mail it to you. I am quite happy to step aside on the coding side if you would like to contribute directly to this project.
Another option is that I could concentrate on a DLNA version which would eventually have a huge market of devices it could work with 
The idea is that we actually manufacture a device developed by forum members
I am using the Volume ++ & Volume-- Commands
These commands are well suited to the Rotary Encoder Control 
Regards, Kevin
@KolfMAKER @zpl1025 @Hydro3 @mclarkdev
I have updated the HW Design Drawings & Prototype Hardware ready for testing next week.
Looking great,
I’ve already added encoder support to my code, so if you decide to try out my firmware, be aware that we used different pin numbers! You will need to update the configuration in Pins.h first.
Here is what I have collected so far for a Requirements overview document. I also have project / task tracking setup on my OpenProject instance, and can grant logins to anyone who wishes. (below text exists as a wiki page)
The main processor the device is an ESP32-S2-WROOM, a device more then capable of preforming the task at hand. Chosen for it's low cost, WiFi capabilities, and Arduino integrations, this processor will allow a wide range of remote control tasks and even allows for OTA upgrades. This processor is so powerful in-fact, we will be under-clocking it to the lowest possible speed which still supports WiFi. Normally running at 240MHz (2x CPUs @ 120MHz), we under-clock our device to just 80MHz (1x CPU @ 80MHz) in order to save as much power as possible from the tiny LiPo pack attached.
Using the ESP32 as it's core, the device will communicate with Arylic devices via the HTTP API.
The device will be powered by a single small LiPo cell, and due to the low-power nature of the device, should last quite a while.
A simple device, the remote has just a simple jog wheel for volume control and 5 buttons which can preform a variety of actions.
A single RGB status LED will be used to indicate all modes and statuses of the device.
This is a very good point to emphasise. If using the drawings that I have posted attention needs to be be paid to the PIN Configuration. To be more precise
#define PIN_DPAD_N GPIO_NUM_26
#define PIN_DPAD_E GPIO_NUM_25
#define PIN_DPAD_S GPIO_NUM_33
#define PIN_DPAD_W GPIO_NUM_27
#define PIN_DPAD_C GPIO_NUM_32
#define PIN_ENC_A GPIO_NUM_12
#define PIN_ENC_B GPIO_NUM_14
#define PIN_LED_R GPIO_NUM_4
#define PIN_LED_G GPIO_NUM_2
#define PIN_LED_B GPIO_NUM_15
Great response and input @mclarkdev Matt. Thanks for thinking & doing with us! 
Very interesting you mention to under-clock the ESP, resulting in low power consumption, but still being able to communicate via WiFi.; brilliant! 
Status LED
Concerning the colors chosen, for the proto typing, any color is fine, as long is it distincts one functionality & meaning from the other.
In the final product I would prefer White for WiFi, like with the Arylic products (white = WiFi, blue = Bluetooth).
@KolfMAKER @zpl1025 @Hydro3 @mclarkdev
I have tried to consolidate @mclarkdev lamp colours with the possible faults we initially listed in the FDS. It looks like this:-
My main comments or propositions are:
Looking forward to your input, Kevin
@KolfMAKER @zpl1025 @Hydro3 @mclarkdev
With a view of moving forwards to the required hardware (BOM) for Prototype V1 & V2 there are a couple of decisions that need some thought/discussion.
However @mclarkdev do you think it will be possible to put it to sleep and wake up with a button touch ?
@mclarkdev do we need another input to the MCU or can we do this off the the microswitches on the ESP32 e.g. mount the board to make them accessible from outside the casing ?
Looking forward to your feedback, Kevin
No power on / off switch. One of the wonders of the ESP32 is it’s super low power consumption in a deep sleep, device can last for months.
The firmware is currently designed to enter a deep sleep after a 12 second period of inactivity (configurable). The device will then wake up at the press of a button.
I am not sure we need a ‘factory reset’ switch as long as we have a way to enter the configuration mode. Once in the configuration mode we can have an option to clear all configuration values for transfer of device ownership or something.
My idea for Configuration mode is a pin-hole micro switch, which when pressed, will boot the device into the BLE Server configuration mode to be connected to by the app.
I plan to use an additional input to achieve this. Once we go to a production device, we will not be using the whole dev-board, but instead just the ESP32 module itself.
Wow! Wow! Wow!
I haven’t read this thread for quite a while (since mid of November last year, I guess), and I’m now less or more out of active coding for personal reasons, but… THIS IS AWESOME! You guys are awesome! Really great work, and I really appreciate it… 
I’m curious what the result will look like and how it will work. Brilliant. 
I get the remark of @mclarkdev , especially the power consumption of the ESP. As long as the ESP is the only component taking power, and we do not have the need of a Mini on the volume knob, perfect.
Question from my side
So we use the ESP to connect to a Arylic device, or group of Arylic devices, and set commands to control it. Right?
Yes we do need to define how it will work re Master, Slave, Group. This will be purely software and functionality and shouldn’t effect the hardware design. @mclarkdev software is a lot more powerful than I had ever imagined and I am sure it will have much wider usage than our simple volume knob
I would like to familiarise myself and use Matt’s software before coming up with any firm suggestions. My next moves are:-
In the meantime I will also prepare something in the FDS that will help us work through the Multiroom side of things.
Regards, Kevin
Why I mentioned this is following. If in the end we need to control volume of a group of Arylic driven speakers, we might need an Up2Stream Mini in the volume know. If that’s the case, we get a different kind of power consumption for the knob.
If we can do just with the ESP, that’s fine. But I am curious how we than handle groups of speakers to be controlled by the knob (in a user friendly way).
@KolfMAKER personally I cannot see any benefit or requirement in having a Mini in the knob box. The KNOB<>ARYLIC interface will essentially be the same whether it is in the box or somewhere else.
I will put myself in user mode and sketch some examples of how it could work with multiroom and check with the HTTPAPI command set from a Web Browser.
Just checking, perfect! 
@KolfMAKER @zpl1025 @mclarkdev @Hydro3
This is a start on the User Experience side of things (also a toe dip for the Marketing Team )
I have 2 Multiroom systems running (1 in UK and 1 in Spain) Tomorrow I will simulate how I would imagine things to happen and document it. For the moment it will be more of a brainstorming type of exercise so I will IGNORE my knowledge of the HTTPAPI Command Set.
So from this exercise please contribute to add
It is clear that this device is not app, has no visual display except some LED colours and therefore should really be benchmarked against the IR Remote Control and not the app. However it is also clear that as with the IR Remote Control a combination of APP Control & Remote Control Device needs to be considered and clearly explained. I am not saying that we should just replicate a subset of the IR Remote Control because we could miss something innovative & useful.
Anyway all your ideas and opinions will be good to have. I will make the Multiroom examples generic so we can all add out own experiences.
