Try this post: MonoPrice 6 zone Whole home amp Driver - #240 by mluck
Thanks for the reply. I was able to get all my zones and sources named appropriately - what I'm curious about is how to make the right dashboard widget to change sources.
There are probably multiple ways to do this. Hubitat doesn't AFAIK have a "widget" concept in dashboard, so I'm assuming what you want is just to control input source from a dashboard simply somehow. Anyway, here's how I'd do it:
- On my dashboard I'd place a virtual button or a variable. A button if you just wanted to cycle through the inputs (1, 2, 3, 4, 5, 6, 1, 2 ....) and a variable if you wanted to type the input name or number directly. Buttons are stateless so that approach would be a little more complicated.
- Next I would create a rule in Rule Machine (RM) that triggers when the button is pressed or the variable changes. The rule would use the setInputSource command for whatever speakers you wanted (and maybe set volume and do whatever else you want at the same time). Pull up the device details page and toward the top you can see the "Set Input Source" command right there -- the RM custom action mirrors what would happen if you used this.
- I would then go back to the dashboard and reference the new rule in the corresponding dashboard tile.
I can't tell from your original post whether each of the above steps are totally foreign or totally obvious to you, but I assure you they are each quite easy. Just ask if you're unclear about anything and I'm willing to help as are many others.
There are probably other (maybe easier?) ways to do what you want to do, so I strongly suggest keeping your eyes and ears open. Cheers....
1 Like
Ok, reviving an old thread here. Started running into an odd issue. I stop getting control from Hubitat to the the Monorprice receiver. If I click "Initialize" from the parent driver, it starts working a little bit then stops again. Initialize gets it working again, then it stops.
Here are the errors I'm getting:
dev:112024-04-01 02:50:52.820 PMdebugfound mach: #>1600000000200707100600
dev:112024-04-01 02:50:52.797 PMdebugParse recive: #>1600000000200707100600
dev:112024-04-01 02:50:52.787 PMdebugfound mach: #>1500000000200707100600
dev:112024-04-01 02:50:52.760 PMdebugParse recive: #>1500000000200707100600
dev:112024-04-01 02:50:52.748 PMdebugfound mach: #>1400000000141214100201
dev:112024-04-01 02:50:52.720 PMdebugParse recive: #>1400000000141214100201
dev:112024-04-01 02:50:52.708 PMdebugfound mach: #>1300000000091114100101
dev:112024-04-01 02:50:52.600 PMdebugParse recive: #>1300000000091114100101
dev:112024-04-01 02:50:52.591 PMdebugfound mach: #>1200000000161214100101
dev:112024-04-01 02:50:52.566 PMdebugParse recive: #>1200000000161214100101
dev:112024-04-01 02:50:52.554 PMdebugfound mach: #>1100010000171012100101
dev:112024-04-01 02:50:52.512 PMdebugParse recive: #>1100010000171012100101
dev:112024-04-01 02:50:52.500 PMdebugParse recive: ?10
dev:112024-04-01 02:50:52.432 PMdebugSending telnet msg: ?10
dev:112024-04-01 02:50:52.415 PMdebugPolling First 6 zones
dev:112024-04-01 02:50:51.395 PMinfopollSchedule 1 minute
dev:112024-04-01 02:50:51.304 PMinfoParent MonoPrice 6 Zone Amp Controller: initialize()
dev:112024-04-01 02:50:25.078 PMdebugSending telnet msg: <11vo20
dev:182024-04-01 02:50:25.066 PMdebug52
dev:112024-04-01 02:50:24.374 PMdebugSending telnet msg: <11vo21
dev:182024-04-01 02:50:24.341 PMdebug54
dev:112024-04-01 02:50:23.804 PMdebugSending telnet msg: <11vo20
dev:182024-04-01 02:50:23.752 PMdebug52
dev:112024-04-01 02:50:23.161 PMwarntelnet input stream closed
dev:112024-04-01 02:50:23.150 PMwarntelnetStatus: error: receive error: Stream is closed
dev:112024-04-01 02:50:22.905 PMdebugSending telnet msg: <11vo19
dev:182024-04-01 02:50:22.892 PMdebug50
dev:112024-04-01 02:50:22.626 PMdebugSending telnet msg: <11vo18
dev:182024-04-01 02:50:22.609 PMdebug48
dev:112024-04-01 02:50:22.331 PMdebugSending telnet msg: <11vo17
dev:182024-04-01 02:50:22.316 PMdebug46
dev:112024-04-01 02:50:21.340 PMdebugfound mach: #>1600000000200707100600
dev:112024-04-01 02:50:21.319 PMdebugSending telnet msg: <11vo17
dev:112024-04-01 02:50:21.284 PMdebugParse recive: #>1600000000200707100600
dev:112024-04-01 02:50:21.276 PMdebugfound mach: #>1500000000200707100600
dev:182024-04-01 02:50:21.265 PMdebug44
dev:112024-04-01 02:50:21.258 PMdebugParse recive: #>1500000000200707100600
dev:112024-04-01 02:50:21.256 PMdebugfound mach: #>1400000000141214100201
dev:112024-04-01 02:50:21.215 PMdebugParse recive: #>1400000000141214100201
dev:112024-04-01 02:50:21.207 PMdebugfound mach: #>1300000000091114100101
dev:112024-04-01 02:50:21.182 PMdebugParse recive: #>1300000000091114100101
dev:112024-04-01 02:50:21.173 PMdebugfound mach: #>1200000000161214100101
dev:112024-04-01 02:50:21.149 PMdebugParse recive: #>1200000000161214100101
dev:112024-04-01 02:50:21.140 PMdebugfound mach: #>1100010000161012100101
dev:112024-04-01 02:50:21.097 PMdebugParse recive: #>1100010000161012100101
dev:112024-04-01 02:50:21.084 PMdebugParse recive: #?10
Also, to add, I'm running command through Putty as well and I'm getting no issues.
I have been running a Russound MCA-C5 system for many years through the Telnet connection. I use webcore with my Alexa/dashboards/phones to control everything. I have struggled for many years to get this right. But I continue to have frequent problems. The rate-limiting-step is the Telnet as it is generally slow and unpredictable. Granted, I have morphed the Telnet device to fit my needs, so I cannot blame the driver. I have been considering switching to the MonoPrice so that I can use IP controls, keeping my webcore-centric design. This change would likely require days/weeks of hardware/software conversion. Any thoughts would be welcome.
Maybe it's just me, but I have frequent problems with the Telnet stream dying. Usual a quick reset is all it takes, but I don't find it to be all that resilient.
And I have two instances, one in each home, so...hopefully ymmv
1 Like
Yesterday my Telnet service went crazy. I did a recent HE update. Not sure if that is the problem. I'm going to roll back and see.
Thanks for the heads up. Let us know if rolling back helps.
Went back to version: 2.3.8.139 and all is well with Telnet. Not sure the recent update is the problem. Will ask the community in a new thread.
I haven't had any issues with mine. I used it yesterday. What are you using for the converter? I bought the cheap $20 for me and at my parent's house. They last about 2 years and die.
Wonder if that's what happened to me. Mine is still showing connected to my network and I can still pull the IU, so I figured it was alive. But the telnet is dead, so...
Will try replacing and let you guys know.
Guys, fwiw I'm fairly convinced my troubles are not coming from Hubitat firmware. Turned out my problem was that I had two integrations (one Hubitat and one HA) that were both using the same serial interface to the Monoprice. When HA was used telnet, Hubitat froze--and vice versa. Maybe there are telnet experts (def not me) who understands why this is.
I use both HA and HE both because imho HE>>HA for automation and HA>>HE for dashboarding. But there are a few situations (this apparently being one) where you can't have both integrations running in parallel.
Anyone know of a workaround for this? I considered using two different serial interfaces, but not sure if I could "Y" into the RS-232 port on the back of the Monoprice. Any ideas?
I do not have a Hubitat hub anymore. I do have HA and it work fine.
I believe that you problem is that the telnet to serial adapter denied access to de second client you need to figure out a way to have two client connected to the same telnet to serial adapter I don’t know if the adapter you use have an option to do that but it may require to use a different port per client, if it was me, I will explore 1 of 3 options
1 - try to research a raspberry pi with telnet adapter last time a check there were a python scrip that could be install in any Linux system as a process that did this but I don’t know if you could connect 2 clients you may have tu run to different instances of the scrip and use some type of software that allow to communicate to a single serial port.
2 - use a computer base system with some type of serial splitter software, when I was in the IT field I use some version of this, it use a 2 virtual port that point to a single hardware port that way you could use 2 different apps on the same computer could comunícate to the same port.
3 - Use a physical/hardware port splitter and 2 different telnet to serial adapters with different IP’s
Hope it help you or at least point you to a posible solution
Jorge Martinez
Edit: On a later idea maybe you could connect the serial to telnet adapter to one hub and use some type of integration that will expose to the other one
Thanks Jorge!
I'm trying to figure out your #3 -- there are RS232 splitters, but I'm not sure if Monoprice 10761 can handle a splitter. I tried calling Monoprice technical support, and that was unsurprisingly a disaster.
If that doesn't work, I'll fallback on your last idea -- connect it to HA and then use HADB to expose it to HE.
Technically with the correct hardware MonoPrice amp don’t need to be aware of the splitter as long as the splitter capture what the amp is transmitting and send it to the 2 output and capture what any of the 2 output send and retransmit it to the amp you should be good serial communication is very rudimentary and not complicated at all.
Is this Monoprice driver bi-directional? What kind of feedback can I expect when issuing commands to the unit?
Not sure what you mean by bidirectional. If you issue a command from HE, it will show up on the keypads. If you invoke the same command from a keypad, it will show up on the HE device. If that’s what you mean by bidirectional, then YES.
I currently use a Telnet connection to my Russound. Initially, the driver did not provide much feedback about the commands that were issued. With some great help from the developer, the driver reports back on the success of the commands. On occasion, a command will be missed, and I can monitor that with the modified driver.
I've never seen anything useful in the logs from the Telnet layer, other than open/closed. If you are using a serial interface, depending on which one, you can monitor some activity. Beyond that, I'm afraid I don't know. Others here might....
