Don Cohen

Same here. I was away from home for around 10 days, returning today, and found it back to its usual behavior.

I was gone for about 10 days, and came home to discover the same thing. It's now working as it used to. No idea who did what, but glad it's back to the way it was.

I started a similar thread a little over a week ago here. Several of us are seeing the same thing.

I would imagine you're correct about that. And while it has been glitchy all along, at least for some of us, it's glitchy essentially all the time, at least for AV related commands, in my case anyway. It seems interesting that things got worse amidst the reported AWS changes that were supposed to make things better. So having that false 'not responding' from Alexa 5-10% of the time was a minor annoyance, having it 100% of the time is quite a different matter. It does actually trigger the correct response, so I'm glad about that. But still...

That's the way it's been in my system all along. Perhaps 10% of the time I get the not responding reply, while it actually triggered the correct response 95% of the time. But for the last week or two, it's been 100% of the time - I get the not responding reply essentially at the same time as the command is correctly executed. I also rebooted my Router this morning, out of curiosity, but no difference. Same behavior.

No change in my home either. I haven't had time to report this to Control4 yet. Any update from your Dealer?

Yes, and I could do that. My situation is a bit unique though, as a part-time post-retirement relationship, and I try to avoid taking their time away for issues that might only be impacting me. But yeah, I should probably go through those channels.

Appreciate the post, and while it sucks for you, at least I know now that it's not something just in my system. How does one bring this to the attention of Control4 staff to investigate?

Interesting. As I indicated, in the past I would occasionally have the "x device is not responding" even though it does, randomly, and relatively infrequently. Now it's all the time. What Control4 OS are you on? I updated to 3.2.4 not too long ago, and have experienced an occasional glitch in conventional Control4 programming at times, unrelated to Alexa. It also may not be coincidental than there have been some recent changes in how Control4 interacts with Amazon servers to improve connectivity (or something along those lines, I forget the details). I'm not sure if my problems originated from when those changes occurred, but it does make me wonder if this fixed some things while breaking others.

I appreciate the reply, and glad you solved your problem, but if you read my original post, you'll see that I've already done that. Several times in fact. My Control4 account was already linked when this started, no "expired" or other message like that. But despite that, I've unlinked manually, done multiple Controller reboots, then successfully relinking Control4 to Alexa, but the problem persists. I tried again this morning with no success. Snap One Status shows no problems for many days, so if there is a problem on their side, they seem unaware of it. And I am unaware of any way to check the status of the connection on Amazon's side. So my problem remains, for a week or more now. Each and every time I give a command involving AV gear, the system responds even though Alexa says it's not responding. Quite frustrating. Anybody else seeing this or not seeing this?

Thanks. At least I know it's not something misconfigured in my system alone. It's always hard to know if it's on the Amazon or Control4 side of things...

Thanks for the reply @Atrunco. In general, I would agree with you. There have been past incidents, outages, etc., which were reported at the Snap One Status page, with resultant Alexa problems, which would resolve within a day or so. The thing is, while some outages were reported on Jan. 19, there have been none reported for the past 3 days. So definitely long enough for things to 'clear.' And even with past problems, I would have the occasional "x device is not responding" from Alexa, while most of the time it would still actually trigger the correct action. But for many days now, every command to my AV system in Theater or Family Room is accompanied by "hmmm....x device is not responding" even though it actually does. Each and every time. So this is worse than in the past, longer lasting, and somewhat different in the nature of the problem.

This behavior remains unchanged. Is no one else seeing this? Hard to believe it's just my system, since it's worked well for so long without this quirk. And any suggestions on how to 'reset' this beyond Controller reboot, and/or Unlinking/Relinking the Alexa-Control4 connection, both of which I've done?

I have been using Alexa to turn on my Theater and Family Room TV for a couple of years: "Turn on HBO Max," "Turn on Theater Netflix," etc. In the past it worked without difficulty probably 90 to 95% of the time, with the occasional glitch. This is with the Control4 native driver, not 3rd party. Previously, every once in a while, after a few second delay, Alexa would say "Sorry...HBO Max is not responding" but immediately after it said that, the device would turn on. Annoying, but no big deal. For the past couple of weeks, it says that the device is not responding essentially right away, and then the device does in fact turn on. So no more delay in the erroneous message, but this is now happening each and every time. This is annoying. I have unlinked Alexa to Control4, then rebooted the Controller, finally relinking Alexa. Then rediscovered Devices. No change in the problem. I have tried a number of variations on this theme, unlinking and relinking without a controller reboot, just a controller reboot, etc. The problem persists. I saw there were some outages a couple of days ago, but these are now reported as fully restored. Am I the only one experiencing this? I could deal with the 1 out of 10 times when it mistakenly said this, but every time is pretty ridiculous. Other Alexa commands (close the garage doors, turn on a light, etc.) function normally without any 'non responding' message. So seemingly, just the AV gear is showing this issue. Thoughts?

My Dealer installed 2 Luma IP cameras, a DS2-Mini, and a Luma NVR (along with A/V, Lighting, Locks, etc.). I later added a Chime VDB. Out of our entire system, I have been least happy with the Luma 510 NVR. It's generally reliable, but can be flaky. I like to have a browser tab open on my 2nd monitor, where I can view all 4 cameras, and have found that the Luma will spontaneously reboot from time to time, requiring me to manually log back into the browser interface. The HD was replaced, then the entire unit, but this problem has persisted - twice in one day, not again for a week or two, but never fully stable. I suspect most wouldn't be aware this occurs, because it does complete the reboot, and restore camera access on its own. And you'd only know if you were logged in at the time, as I am with my browser. And another time, out of nowhere it lost the feed from the 2 IP cameras. We had to do a partial reset of the Luma itself to restore functionality. So if I were choosing a system today, I would keep essentially everything else Control4-wise in general, but would definitely be looking at different NVR options. FWIW.

Is anybody seeing any odd behavior since upgrading to 3.2.4? I upgraded a week or two ago, and while almost everything is working fine, I have the occasional odd glitch. The main thing is in my Theater - I have had simple programming in place there for probably close to 2 years, which has performed flawlessly, to activate a particular lighting scene and put the AVR on Mute, when my Theater first turns on. Since going to 3.2.4 I've found that sometimes this works, and sometimes it doesn't. I can't identify any reason for why it doesn't always work, no particular situation or scenario that is causing this odd behavior. I removed the programming commands in question, and then put them back in. It seemed fine for a day or two, but once again I turned on the theater, and the lights remained unchanged, and the AVR was not muted. A friend of mine does some Control4 driver creation, and participates in a programmer/developer group on FB, and he said others were reporting similar glitches with 3.2.4. I'm guessing there's nothing I can do about it until Control4 releases an update, but was just wondering if anybody had any similar experience, or has any suggestions on how to remedy this.

Many thanks for the reply. To add the Chime to the NVR, I followed the instructions provided in the document provided by Snap One, and the Custom Protocol used shows RTSP, with no mention of ONVIF. This corresponds to the IP Address and RTSP Port shown for the Chime VDB in Composer. In the Luma, I'm using live.sdp for the Main stream and live3.sdp for the Sub stream. Hmm...I'm sure I read that this is what I should use for the Sub stream somewhere, since I would have no reason to do otherwise. I may be mistaken but I recall the Illustrations in that document showing live3.sdp for Sub stream at one point, and I followed that. Regardless, I just changed Sub stream to the same live.sdp to see what happens. I rang the bell, and once again it froze in Luma, continuing unchanged in Control4. I then checked Live View Parameters on the 'Configure this Computer' page of the Luma. For Stream type it showed Mixed Stream and Image size was at 16:9 (I didn't set the NVR up when it was first installed, so don't know why this was chosen). According to the Chime document these should be Main Stream and Auto-fill. I changed those, and that seems to have fixed it. Thanks again - you got me pointed back in the right direction - rtfm!

The title says it all. Whenever someone presses the Chime VDB button, I lose the Videofeed in my Luma 510 NVR. I have to reboot the VDB to get it going again. I have an Edge Browser window open that is logged into the Luma NVR and shows the 4 cameras in my home. I keep that open on my second computer monitor, so I can readily see when this happens. I am now on 3.2.4, but this also happened with 3.2.2. All Drivers and Firmware appear up to date. When this happens, I can still see the camera's Videofeed using the Control4 App. I have programming using the Chowmain SMTP Driver to send me an email when this button is pressed, but this problem occurs even when I disabled this. Any thoughts or ideas welcome, as well as additional troubleshooting steps I can take to track this down.

I never had this problem until today. I was on 3.2.2 (T3 was on 3.1.1 for some reason, possibly because I had done a warranty exchange on it not too long ago), and everything was fine. I upgraded everything to 3.2.4, and my T3 suddenly started showing the Indoor temperature, rather than Outdoor, as specified in the T3's setup. I fixed it by configuring it in the UI Agent, as suggested above, and rebooting the T3. So apparently this problem has not yet been fixed, and I'm posting to report a specific scenario that actually triggered its occurrence, in case that might help pinpoint its cause.

Thanks for the reply. The reason I posted is that it seems this new Firmware is provided directly by Wyze, along with instructions from Wyze on how it gets installed. So I understand what needs to be done, along with the caveats provided by Wyze. The question is whether or not this new Firmware, provided by Wyze, is different from the one linked to by Chowmain, and if it is different, whether or not the Chowmain driver would still work.

Sorry to dredge up an old thread, but this seems relevant. It seems that Wyze is now providing their own firmware to enable RTSP, as of Sept. 28, 2021: Wyze Cam RTSP Will this still require, or even be compatible, with the Chowmain Driver @alanchow ?

That is awesome, Chris - much appreciated. This has been one of my few significant complaints using Control4, so it would be awesome if this could be improved.

Is there anybody from the 'Android team' who similarly monitors and participates in the forum? I have a Chime VDB where sometimes a button press initiates a call to our phones, and sometimes it doesn't. A reboot of the doorbell typically gets it going again, but this is a function that should be rock solid, with only a rare need for intervention at the most. And with my new phone (Galaxy S21 Ultra), answering a call from my DS2 Mini or Chime VDB is cumbersome and inefficient: unlock the phone, swipe down the notification bar, tap the notification, wait until the app opens, and then tap the icon to answer the call. And there is typically a lag between when the button is pushed and the phone gets the notification to begin with. So often the person is gone by the time I can answer the call. Thanks!

I've had a Control4 system for about 2 1/2 years now. Before that I was mainly a DIY guy with Harmony, Alexa, Google, etc. It was a retro-fit in my home, installed as part of my employment with a Control4 Dealer. We now use it to control Lights, HVAC, Door Locks, Garage Doors, Security Panel, AV Gear (including a fairly complex Home Theater, with a motorized curtain on the screen), a Moen Flo Water shutoff Valve, a few Security Cameras (with NVR), along with a DS2 Mini Door Station and most recently a Chime Video Doorbell. Overall I am extremely pleased with the stability, reliability, and especially the integration of all these systems. For the most part, it just works. I do like the multiple ways of accessing the system: a 10" T3, Android Phone Apps, SR-260 Universal Remote, and voice integration with both Google Assistant and Alexa. (Alexa is perhaps 80-90% reliable, so does occasionally glitch, but I don't know that I can fault Control4 for that.) The main area where I have been disappointed is with the DS2 Mini, Chime Doorbell, and (Luma) NVR. Perhaps it has to do with having Android Phones, but the Intercom function is just not quick and reliable enough to be depended on. And the quality of audio communication (mainly the DS2 Mini) is just not what it should be for the money spent. I like to have the feeds from our Luma external cameras on my 2nd computer monitor, and IE until very recently was the only option. And out of nowhere, even though the NVR worked, the Luma App on our phones worked, I couldn't get the camera feeds visible in IE. I had to do a partial reset of the NVR to get things going again. Also, the NVR will spontaneously reboot every now and then. Edge can now be used, with some tweaking of settings, but I still can't get the Luma cameras loaded when using Chrome. All things considered, and given what I've learned over the last few years, I'd definitely still go with Control4. But I might consider some other options regarding Video Doorbells and Intercom function, and likely a different brand of NVR and/or Cameras.

I went through this not too long ago, and the only way I found to delete them was to go to the individual posts where they were attached, and delete them there. If there's a better way, I'd like to know as well.