Great work & progress again @NWT.Stuff Kevin, thanks!
@mclarkdev: Matt can you comment, or send a link that shows the example of LED with integrated reset switch?
No single part - just a reset switch near the indication LED.
In our product case, the âlight pipeâ which will redirects the illumination from the PCB LED to the small hole in the case can double as a pressable object to trigger the button.
Oops sorry @KolfMAKER I didnât get the âlight pipeâ thing. I do now (hopefully) 
Regarding Testing of PV1 with @mclarkdev Latest Software, absolutely no bugs to report right now :). However I have been using it sporadically which is actually a good test for such a device. Just Wakes Up and does the job asked 
Just one note I have in mind that if the Production Device is with configurable buttons (=HTTPAPI commands) then it needs to be accompanied with good and clear advice about which HTTPAPI commands are suitable for the device. For example a list of recommended tested and validated commands. Accompanied with a disclaimer for the rest; someone will always find an obscure command that doesnât really work. This could then become an âapparentâ bug in the NVS unit but in reality it is a limitation or oversight on the HTTPAPI side.
I am happy to prepare the list and test with multiple sources e.g. NAS, USB, Spotify, Tidal, Deezer etc.etc. This is really just testing the âhttpapiâ instructions but the Clients/Purchasers will probably only see this side and wonât even know what an âhttpapiâ is !!
This is the sort of scenario I envisage
Anyway I will carry out the the tests and report back. It is certainly not a bad test for the Unit & Software as a button pressed is a test in itself. And the more buttons pressed means tested more and more.
I am thinking it is really nice to make a super flexible unit for the educated but however keep it simple for most folk. Maybe we could even have a command filter @mclarkdev that only allows tested and validated httpapi commands.
Anyway just thoughts for now. The proof is in the testing
So finally Questions about Testing Table (exclude Configuration & Multiroom for now):
Q Any other sources / inputs / services to include ?
Q. Any other httpapi commands of interest for this device ?
Many Thanks in advance, Kevin
Hi, you should also consider
- Sources - wifi (airplay)
- how do you choose the preset number (by sequential clickings, like source?)
- standby/power of the controlled device
- EQ (treble and bass ±, and Depp Bass)
- pause/resume is the same button
best regards
1 Like
Ok, that clears things up, thanks @mclarkdev Matt.
I will do following. In the design of the casing for prototype v1, I will keep it simple. The LED will be integrated in the top of the casing underneath a thinner layer of the casing. As the casing will be produced on a 3D printer, I can create a holder for the LED in the top of the casing on the inside, and make the plastic layer between the LED and the outside thin. In such way that it will shine through. So the surface will be even everywhere, but LED light will shine through.
If during the design process I see easy ways to implement a press-able light pipe, I will do that. If not, Iâll do that for v2.
All 3D design files/3D printable files will be shared later on.
@NWT.Stuff I like this suggestion. It keeps our product flexible and useable for any audience. 
1 Like
@KolfMAKER Sounds good for me 
As PV2 is reserved for a close to Production Type Unit I would suggest that to keep things clear we introduce variants to Prototype V1. e.g.
PV1A = My unit in UK
PV1B = Your Unit
PV1C = Reserved for @Hydro3 build
PV1D = Reserved for @mclarkdev build
etc.
Already looking forward to seeing the end result
That will be excellent once you have a working design
Hi @sage Jurica,
Many thanks for your comments. Before I address them I will explain some stuff. The Current Prototype is working on 1 to 1 communication sending HTTPAPI Commands to a paired Arylic Device.
Other communication protocols could be introduced at a later date (e.g. DLNA, BLE,
UART Passthrough TCP/IP) . I have updated the test report to take into account your comments.
Not possible with HTTPAPI. In fact your question led me to check all Input Sources possible so you will see the options in the new sheet.
To be defined however on Prototype V0 I was indexing presets +1 with DOWN button & preset -1 with UP. I am sure accessing the 10 available PRESETS will be a popular feature.
Added to Test Sheet
Commands not available in HTTPAPI, From memory in the other protocols:-
DLNA - No
UART Passthrough TCP/IP - Yes
BLE - Not sure - this is very new
I agree, however there are 3 commands available in HTTPAPI. I have added comments to the test sheet to reflect this.
Thanks Again for the Feedback. The Test Document is much better and more complete now.
Kind Regards
Kevin
from âARYLiC TCP API.pdfâ
This is not httpapi but is UART Passthrough TCP/IP. Itâs a different command set and Communications approach using TCP/IP sockets instead of HTTP Server.
Yes WIFI is a source (white LED on Arylic Products) which covers PULLING My Music & Music Services. Also accepts PUSHING from Airplay, DLNA etc.
With this type of device we can just place it in WiFi mode BUT the actual audio content will be selected on the mobile device with PULL with 4STREAM APP or PUSH with 3rd Party APP (Airplay, DLNA). I do believe it picks up the last selected audio content (e.g. if playing from NAS, then listen to Aux In, then switch back to Wifi Mode the NAS content will continue - iâll test this to be sure what happens)
Hope this clears things up
This is my understanding
@zpl1025 Can you confirm if this table is correct ?
Hi Kevin, the TCP/IP commands are common for Linkplay compliant devices, but Acylic extended some extra commands with the passthrough feature, normally to control the base board directly, for example, the EQ/max volume/balance etc.
Thanks Frank @zpl1025 so we have this ?
@KolfMAKER @Hydro3 @mclarkdev @zpl1025
I have produced 2 case studies to try write down how this product COULD be used.
It would be good to have as many case studies as possible to have good feedback that could drive the Final Hardware Design & Options ,Software Capability, Instructions & Marketing.
This post is not necessarily targeted at the tagged forum users. We would like as many users as possible to express how they would see the possibilities of a wifi control unit as opposed to the existing IR Remote and 4STREAM APP.
Kevin,
I will work on doing up a case study for my use. I guess I forgot to order my rotary encoder so it will be here in a couple of days and I will build a test unit to see how it works with my system.
Right now I have 3 groups of speakers (2 groups with 2 speakers each, and a group of 1).
After I get the NVS remote working I will start to build a couple more speakers that will be portable. I will probably be looking at an end game of 2 NVS remotes that can control the multispeaker groups since the portable speakers will end up joining these groups depending on where they are located.
Good job on the write up.
2 Likes
Ryan
That will be great. The more examples of really useful practical usage should lead where we go with this ultimately from the functionality point of view
Will be good to have more input. Donât just follow my examples; would be a shame to miss out on some important info or an alternative format that could merge into a really nice way of describing what the device will or could do 
Good luck with the hardware and prototype build 