Searching for: Volume control button that connects with Arylic Up2Stream

[KolfMAKER]

@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.

[NWT.Stuff]

@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

[mclarkdev]

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.

Firmware on GitHub

There are some improvements to be made for sure, currently the device supports only 5 functions:

• N: Set volume to 80%
• S: Set volume to 40%
• E: Next track
• W: Previous track
• C: Pause

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!

[mclarkdev]

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

[NWT.Stuff]

@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

[NWT.Stuff]

I am using the Volume ++ & Volume-- Commands

API Files for Developers

@joy @zpl1025 @phranck I have noticed a couple of commands that are missing from the HTTPAPI. Volume ++ (Increases Volume by 7 steps (in the 0-100 Range) http://192.168.xxx.xxx/httpapi.asp?command=setPlayerCmd:Vol%2B%2Bn Volume – (Decreases Volume by 7 steps (in the 0-100 Range) http://192.168.xxx.xxx/httpapi.asp?command=setPlayerCmd:Vol--n Sorry this was my fault as I obviously didn’t check all the commands at the time. I am happy to correct and have another sweep through the documentati…

These commands are well suited to the Rotary Encoder Control

Regards, Kevin

[NWT.Stuff]

@KolfMAKER @zpl1025 @Hydro3 @mclarkdev

I have updated the HW Design Drawings & Prototype Hardware ready for testing next week.

[mclarkdev]

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)

---

Processor

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.

WiFi Connectivity

Using the ESP32 as it's core, the device will communicate with Arylic devices via the HTTP API.

Power

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.

• Single Cell LiPo (500mAh?)
  • LDO Regulator for stable processor voltage
• Ability to self monitor battery voltage
  • GPIO drives a transistor to enable a voltage divider
  • ESP32 reads analog voltage across divider
• MicroUSB input for battery charging

Input

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 directional pad will be connected on pins N(#), E(#), S(#), W(#), S(#)
• A jog wheel encoder will be connected on pins A(#), B(#)

Status LED

A single RGB status LED will be used to indicate all modes and statuses of the device.

• A status LED will be available on pins R(#), G(#), B(#)
• Different colors and pule counts will indicate device status
  • Purple solid
    • Connected to WiFi
    • Fades to [0] with inactivity
  • Purple flashing
    • Connecting to WiFi
  • Blue flashing
    • Unconfigured / Setup Mode
  • Red
    • Number of flashes indicate error code
      • Error connecting to WiFi
      • Error when making API call
      • Low battery

BOM

• Encoder [Link] [$8.95/ea]
• Encoder Board [Link] [$1.50/ea]
• ESP32 Devkit [Link] [<$10/ea]
• Battery Hypervisor [Link] [<$.80/ea]
• RGB LED

[NWT.Stuff]

@mclarkdev

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.

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

[KolfMAKER]

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).

[NWT.Stuff]

@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:

• Avoid Blue for now. Intrinsically linked with BT on Arylic Devices. Also there could still be a BLE Version of this device !
• Q. On configuration - Good Idea to distinguish between WIFI OK and Comms ESP32<>Arylic OK. This could be Arylic not paired (during config) or as Matt states an Error Making API Call (during normal use).
• Q. Is it worth having a colour reserved for the battery ? e.g. Yellow ?
• I am pretty sure we will all be agreed on a flashing red for any “malfunction”

Looking forward to your input, Kevin

[NWT.Stuff]

@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.

1. Power ON - OFF Switch ?
   I am thinking as the device doesn’t need to be used constantly e.g. only when listening to music a little switch to knock it off completely is not a bad idea.

However @mclarkdev do you think it will be possible to put it to sleep and wake up with a button touch ?

2. Factory Reset Microswitch
   I am presuming not a bad idea to have one.

@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

[mclarkdev]

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.

[phranck]

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.

[KolfMAKER]

@NWT.Stuff

1. Power ON - OFF Switch ?
   I am thinking as the device doesn’t need to be used constantly e.g. only when listening to music a little switch to knock it off completely is not a bad idea.

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?

[NWT.Stuff]

@KolfMAKER

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:-

• create parts list for prototype V1
• test and understand Matt’s approach
• Finalise Status lamps definition & colours etc.
• Test Prototype V1 Fully with Single Device connection
• define/discuss/propose Functionality and Configuration with multiple devices

In the meantime I will also prepare something in the FDS that will help us work through the Multiroom side of things.

Regards, Kevin

[KolfMAKER]

@NWT.Stuff

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.

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).

[NWT.Stuff]

@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.

[KolfMAKER]

@NWT.Stuff

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.

Just checking, perfect!

[NWT.Stuff]

@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

• Why how to use the unit ?
• Frequent Operations I have missed.

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.