Hi,
it is very difficult for me to support, because I do not have your hardware, you never confirmed the version you are using and now you start editing code - it is like cycling blindfolded…
I assume, the lines containing HEX are what you added, because my code does not contain HEX anywhere. The hexadecimal value behind the HEX: prefix is the ASCII representation of the command you want to send + the carriage return - but since I do not know the code you added, I do not know what it is supposed to show.
The same section in my log looks like this:
info: [SERIALAMPCONTROLLER] on:pushState: amp in standby - send powerup after play pressed
info: [SERIALAMPCONTROLLER] sendCommand: send powerOn
info: [SERIALAMPCONTROLLER] sendCommand: now sending cmdString: power_on!
info: [SERIALAMPCONTROLLER] on:pushState: undefined - play
info: [SERIALAMPCONTROLLER] on:pushState: amp in standby
info: [SERIALAMPCONTROLLER] on:pushState: amp in standby - send powerup after play pressed
info: [SERIALAMPCONTROLLER] sendCommand: send powerOn
[... 8x more ...]
info: [SERIALAMPCONTROLLER] sendCommand: sent cmdString: power_on!
info: [SERIALAMPCONTROLLER] sendCommand: send source,Opt1
info: [SERIALAMPCONTROLLER] sendCommand: switch to source: Opt1
info: [SERIALAMPCONTROLLER] sendCommand: now sending cmdString: opt1!
info: [SERIALAMPCONTROLLER] sendCommand: sent cmdString: opt1!
info: [SERIALAMPCONTROLLER] [parser:data]: Listener received: power=on
info: [SERIALAMPCONTROLLER] parser:data: call processResponse with: respPowerOn
info: [SERIALAMPCONTROLLER] processResponse: Amp signaled PowerOn. Previous state is: standby
info: [SERIALAMPCONTROLLER] processResponse: Amp Status is now {"volume":15,"mute":false,"power":"standby","source":"opt1","Powering":""}
info: [SERIALAMPCONTROLLER] [parser:data]: Listener received: source=opt1
It tells us, that we received a state change from Volumio (e.g. from stop to play) and that PowerUp on Play is enabled, so we lookup the PowerUp string from ampCommands.json and send the command via the serialport.io. Because the Amp is slow and Volumio is tipsy, we receive the Status change message another 8 times before the serialport.write calls its callback-function and we see the sent cmdString message (which confirms that the message was sent via the interface, not yet the ACK from the amp). Then we send the command to change to the selected input (Opt1 in my case) which is safe, since it is buffered in the interface and receive the confirmation it was sent.
After that, the parser informs us, that it has received the ACK messages from the Amp. (power=on and later source=opt1).
In your log it looks like you successfully send the string via the serial interface (the call to serialport.write in line 845 of the index.js returns and calls the callback-function (due to missing timestamp, I cannot say how long it took, in my case it is <1 second).
But that does not do anything yet - it is now waiting for a response from the amp, which should trigger a response of the parser. The listener is defined in line 517ff. Whenever it receives data on the serial interface, it will try to find a matching instruction in the ampCommands and trigger an action.
At the bottom of the first post of this thread you can find instructions on a low level test of the interface without the plugin (collapsed section). Please try to get that working, before making changes to the code of the plugin! If you need support post your findings here.
Once you have connected the terminal for echoing the commands from the amp, you can connect a second terminal to your Volumio device and echo commands to the amp by using echo -e -n vol_15! > /dev/ttyUSB0 (replace vol_15! by your command and the path by the path of your serial device (below is an image of how to do it with 2 terminals).
you are under no obligation to support me. Please don’t feel otherwise. I am just hoping you can give some input without too much effort; for which I am grateful!
I have started by having trouble finding the plugin, even after enabling “Plugins test mode” in /dev/. I have not been able to figure out why. So I have downloaded from:
and installed by using the command volumio plugin install
While in the folder.
After this, I have altered index.js in order to make it put out more detailed logging. Right now as I am typing this I am experimenting with doing a little more, i.e. removing “reqModel” from getAmpStatus. My amplifier does not support it. Right now it seems to work, but I have had false hopes before.
When I have something that I am confident is working, I can consult you regarding how to put i back in your code.
Hi Søren,
don’t get me wrong - it is not that I do not want to support, but I feel you are making it unnecessarily complicated. Maybe let me give a few hints:
Can you please try to check, if the plugin is still not shown in the beta channel? As balbuze observe on May 1, it was invisible for you due to the missing support flag for arm64 architecture. But I added that on Bookworm and on Buster in version 2.7.1.
Whenever I am adding a new commit to the branch you linked to in your post, there will be a new “version” of some files and not every commit I make is operational. So even with the link to my repository I do not know, when you pulled your copy - you could still have an old version or worse, you could have pulled an intermediate commit that is buggy. You can check the version of the code on your device by checking line 3 in the package.json file and there can be multiple commits on the same version, so I additionally need to know the commit you downloaded. This is all excluded if you take the version from the plugin store - which I control before publishing.
I tried to find a documentation of your amp but did not find any. The easiest would be, if you make a table with two columns: left colum command sent to the amp, right column response from the amp. Additionally try all the commands with the two terminals as described in the screenshot in my last post.
In Terminal 1 (replace 115200 by the Baud-rate of your amp, ttyUSB0 by the device-name of your serial interface:
In Terminal 2 post the commands now, one by one and then check what response you see in the first Terminal:
echo -e PWON\r > /dev/ttyUSB0
If the terminal test is not properly working, modifying the plugin is wasted effort.
You do not need to modify the code to remove “reqModel”, it is not used for anything and if you provide an empty string in the config file it will not even be sent. With the table finished and verified I can help you make the correct config. If after that, there is anything not working with the current code of the plugin, we can check if we can do something about it.
I’ll start over. Regarding plugin availability in the plugin store, it is not visible now, nor has it been an any point. I am out of my depth here, but would it not require that the serialampcontroller plugin in https://github.com/volumio/volumio-plugins-sources be updated? It has not been updated in two years?
Whenever I make changes on my system, I commit the changes to my fork of the volumio-repository (also, if the plugin is currently not working).
When I have a working update, I issue volumio plugin submit which submits the working version to the beta channel of the plugin store (in this moment it appears in the list of beta versions in the plugin-store, but I think it is still downloaded from the fork).
After I have confirmation from users, that the plugin works, I issue a pull-request in Github, which will trigger the updates to be pulled into https://github.com/volumio/volumio-plugins-sources.
However, the volumio team is not acitively supporting the old plugins anymore, because they want to spend all energy on Volumio 4.
Nevertheless my pull-request #400 was merged yesterday, so there is a new version in the master branch now. Feel free to use that one to play - but Buster is outdated.
Finally: I can only repeat bullet 3 from my previous post: try to get it running via the Terminal first, if that does not work, the plugin won’t work either.
