Yep, looks like you’re right, Brian. I get this in the logs.
2022-10-10 16:33:49.571 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration nuvo_simple which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2022-10-10 16:33:55.670 INFO (Thread-2 (_listen)) [nuvo_simple] Attempting connection - "socket://192.168.1.26:59001" at 9600 baud
2022-10-10 16:33:55.686 ERROR (SyncWorker_4) [custom_components.nuvo_simple] Error opening serial port
2022-10-10 16:33:55.686 ERROR (Thread-2 (_listen)) [nuvo_simple] Could not open serial port.
File "/usr/local/lib/python3.10/site-packages/nuvo_simple/__init__.py", line 627, in _listen
2022-10-10 16:33:55.700 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration nuvo_simple: Integration failed to initialize.
I tried to Telnet to the port on the RPi and can’t get a connection. I rechecked the config files and it all aligns with yours. The only thing I really changed was the port name. From your instructions, I used the full port name which for me is usb-FTDI_FT232R_USB_UART_AB0MDF75-if00-port0. I set up the nuvonet file as follows:
Hi again. Some further experimentation led me to try pyserial, which works on my Russound amp. That allowed me to Telnet to the RPi and send commands to the Nuvo and it actually works. I.e. I can send a zone ON command and the zone turns on. When I use pyserial to connect to your integration, I get the following in the logs:
2022-10-10 18:12:02.541 INFO (Thread-2 (_listen)) [nuvo_simple] Attempting connection - "socket://192.168.1.26:1337" at 9600 baud
2022-10-10 18:12:02.559 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:03.663 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:04.767 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:05.758 WARNING (MainThread) [homeassistant.config_entries] Config entry '192.168.1.4' for yamaha_musiccast integration not ready yet; Retrying in background
2022-10-10 18:12:05.870 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:06.972 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:08.074 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:09.177 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:10.279 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:11.381 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:12.484 DEBUG (SyncWorker_2) [nuvo_simple] Sending "VER"
2022-10-10 18:12:12.536 WARNING (MainThread) [homeassistant.setup] Setup of nuvo_simple is taking over 10 seconds.
2022-10-10 18:12:13.586 ERROR (SyncWorker_2) [nuvo_simple] This does not appear to be a supported Nuvo device.
2022-10-10 18:12:13.589 ERROR (SyncWorker_2) [custom_components.nuvo_simple] This does not appear to be a supported Nuvo device.
2022-10-10 18:12:13.590 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration nuvo_simple: Integration failed to initialize.
So I think I can conclude that my cable works, the RPi works and the Nuvo connection works but for some reason I can’t get your setup to work either with ncat or pyserial. Hopefully this gives you some clues?
Hi again. Some further experimentation led me to try pyserial, which works on my Russound amp. That allowed me to Telnet to the RPi and send commands to the Nuvo and it actually works. I.e. I can send a zone ON command and the zone turns on. When I use pyserial to connect to your integration, I get the following in the logs:
That’s awesome! Sounds like you are close.
Hmmm, one is I noticed is you changed the port from the first run from 59001 to 1337 on the socket connection. That’s totally fine as long as ncat is running on port 1337 now as well, which means you would have changed the 59001 to 1337 in the shell script.
The PORT setting needs to be the full device to the serial port, so you were correct in putting the whole thing there. If you were running the “nuvonet” as a service, you would need to run “systemctl restart nuvonet” after modifying the shell script for the new setting to take effect.
So, I assume things work fine when you telnet to port 1337 and you can send commands to the Nuvo. I don’t know what you’re running on the RPi to make this happen though. Is it ncat or something else?
For the time being, until I find a few days of spare time, you’re going to have to use ncat to make this work. Using something else more than likely will not as it won’t support two connections at the same time.
I used pyserial (here) to telnet on port 1337 to send serial commands. It just happens that it was configured for port 1337 so that’s what I used. NCAT doesn’t work for me. Can’t telnet to it. I used your 59001 port for that. I used two different SD cards to make sure nothing got messed up.
I installed pyserial using these instructions, if you of a mind to try it out. I don’t know if it supports two connections you mention.
I just tried this and unfortunately it does not work. If you run the shell script for ncat manually, does it give you any errors that might point to where the problem would be?
I really screwed up here! I made a mistake and copied an old line I tried when updating the documentation. Just remove “localhost” from the command and it should work fine. Sorry about that!
Wait up! I just realised a screw-up in the naming of the port in these latest edits. Too many copy/pastes. I changed that and we have some progress. I can now Telnet to the port. If I type in *VER, it responds with #MPU_E6v1.09. I can send commands via Telnet like turning on a zone and the Nuvo turns on the zone. So the comms is working between the Nuvo and the RPi. That’s progress! I then went into HA and restarted it. Now the logs return:
2022-10-12 08:36:18.237 INFO (Thread-2 (_listen)) [nuvo_simple] Attempting connection - "socket://192.168.1.26:59001" at 9600 baud
2022-10-12 08:36:18.253 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:19.355 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:20.458 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:21.560 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:21.848 WARNING (MainThread) [homeassistant.config_entries] Config entry '192.168.1.4' for yamaha_musiccast integration not ready yet; Retrying in background
2022-10-12 08:36:22.667 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:23.771 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:24.874 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:25.976 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:27.079 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:28.181 DEBUG (SyncWorker_1) [nuvo_simple] Sending "VER"
2022-10-12 08:36:28.223 WARNING (MainThread) [homeassistant.setup] Setup of nuvo_simple is taking over 10 seconds.
2022-10-12 08:36:29.284 ERROR (SyncWorker_1) [nuvo_simple] This does not appear to be a supported Nuvo device.
2022-10-12 08:36:29.287 ERROR (SyncWorker_1) [custom_components.nuvo_simple] This does not appear to be a supported Nuvo device.
2022-10-12 08:36:29.288 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration nuvo_simple: Integration failed to initialize.
I left Telnet open and I can see multiple responses of #MPU_E6v1.09. It seems that the RPi is getting the messages but for some reason, HA isn’t getting the responses? Or isn’t understanding the responses? At least we’re making progress. I feel like we’re close.
Ok, maybe I have it figured out now, after taking several machines to the Nuvo and plugging in the serial port. You need to add “raw” to the end of the stty command. I will update the documentation. On some models of USB adapters I used, it would not work until I put that in there. Another key thing is you should see everything on a single line on the telnet session. These Nuvos do not send a newline character, so if you see everything scrolling up the screen, it’s not going to work, as something is adding one.
You should see in the debug logs “Received:” messages with every packet it sees.
Furthermore, the version MPU-E6 was not programmed to work. The protocol docs and mine issue a MPU-E6D. I will update the program integration in a few minutes to handle this. You should see an option to upgrade in HACS. Let me know how it goes!
I’m really sorry, Brian. You’re right. Mine does in fact respond with #MPU-E6Dv1.09. I wasn’t paying enough attention. Sorry to have made extra work for you. I’ll try your suggestion re: adding raw to the stty command and report back.
SUCCESS!!! That was it, Brian. I added the ‘raw’ to the stty command, updated your integration in HA, restarted and BOOM. No errors and I could create a dashboard with all the zones being controlled. So far, everything seems to be working. I’ll give it more of a workout but for now, it all looks good.
Thank you for your perseverance and work on this! Hopefully our trials save others some effort to get it working. I’ll no doubt come back and seek your counsel once again as I play around with setting up some more advanced dashboards but at least it’s all working now! I owe you a beer or three. Let me know if you ever find yourself in Brisbane, Australia and I’ll meet you at the pub.
Just adding to this, you’re absolutely right. Until I added the ‘raw’ to stty, the telnet session was showing a bunch of weird indents, suggesting that there were carriage returns in there. Now looking at telnet, everything is on the one line. I think you nailed it.
I’m glad it’s working! That network serial port thing was something I never even thought of before but it makes sense that many people would not have a HA server right beside the Nuvo. I’m sure our work willl pay off if anyone else wants to use the network. Would love to visit Australia sometime, that’s for sure. Everyone I’ve ever talked to down that way is so friendly!
I’ll put some more examples and stuff on github this week. I need to do some work on my own dashboards as well. One thing I would like to do is have the controls for the currently selected source be the only ones that show up for a room dashboard. Should be pretty easy to do but I haven’t got around to it yet.
That would be fabulous. The example you have on there at the moment looks great and I’ve finally figured out what to do with it (still very much a HA noob), so have a test dashboard implementing one zone with your example. I really like it and has given me impetus to keep playing around with it. I have a lot to learn, so any examples are really appreciated. It’ll save me endless searching and experimenting.
It sounds like you’re in the northern hemisphere then? Your name suggests you’re of Irish origin but the Irish are all over the world, so not necessarily where you live.
Nice! Sounds like you’ve got a good working set up for speaker groups now and even have volume offsets working.
I’ve done a complete rework of the speaker group implementation. After trying to make use of Nuvo groups (which only syncs source changes) I decided to remove this and just make speaker groups a pure HA thing as it was becoming very very messy! Way too many state checks needed done and with async operations making timing of events unclear it was hard to reason about so I scrapped it . Wish I’d gone this route originally as it’s much simpler now, but when the system offers a feature like that, you think why not use it
Downside is groups are temporary and lost across HA restarts, but that’s not a biggie and can easily be recreated at startup with a service call.
Upside is it now supports multiple speaker groups.
In order to support a physical zone with keypad as group controller, I’ve lost the ability to determine if a volume change was a volume set or a volume up/down operation, everything is just a volume state change now, so no more doing a volume up on the controller and having that do the same on a group member and maintain any local offset. Local offsets are still possible by altering member volume, but any controller volume change will resync the volumes. I’ve not done anything on configurable volume offsets, need to take a look at how you’ve handled it.
I am running the latest HAOS on an RPi with HACS installed and the 2.0.0 version of this custom integration installed and connected to an NV-E6G. My Nuvo system isn’t used much, so it is frequently sleeping. Because of this, I get an error anytime I try to turn it on. If I correctly remember previously reading this thread, the fix I am replying to is for that (or a similar) issue. However, since the issue was known and addressable prior to some subsequent updates, and possibly because I read (or dreamed) that it was called out as fixed, I thought maybe that issue was one of the fixes in Legrand Nuvo multi-room audio support - #88 by sprocket-9 or v2, so I didn’t want to attempt this fix if I may be looking at a different issue. To be clear, I basically get an error like this when trying to turn on a zone, but I can successfully turn on any zone afterwards:
Failed to call service media_player/turn_on.
RESPONSEREADER: Timeout waiting for response to message: *Z2ON
The 2 in “*Z2ON” is the zone number in this example, so it varies depending on which zone I am trying to turn on, and I won’t see the error again until all zones have been off for a while, so between that and the fact that I can get the error for any zone, but only once at a given time, I am confident that the issue is related to the Nuvo sleeping.
Is this fix for that, and if so, is it still applicable to v2? Otherwise, is there something else I might have missed or anything I should try to work around or help diagnose/troubleshoot my issue?
. Wish I’d gone this route originally as it’s much simpler now, but when the system offers a feature like that, you think why not use it 