RyanE

C4 hasn't made any official announcements on c4 about mqtt that I'm aware of or have given the ok for 3rd party usage. From my understanding, whilst some services might exist, there is no guarantee they would continue to operate (or even exist) in future releases if C4 hasn't given the ok (it would basically be considered an unofficial API at this point). 

Yes, it is - no technical hurdle (that) can't be overcome by spending a number of resources...which is where the business decision comes in.
No-one's saying it wasn't 'business' - the differentiation is that it's not a 'money grab' by forcing people to upgrade gear (again, you're not forced to update right away at all) for the heck of it - but a decision to not waste limited resources on something that doesn't make sense to keep supporting.

The tilde is not used as XOR in Lua.
You would need to use the bit.bxor call in the bitlib library, which is included by default in DriverWorks.
Something like this is your checksum algorithm in Lua:
function XOR_CS(data) local cur = 0xFF data:gsub(".", function(c) cur = bit.bxor(cur, string.byte(c)) end) return cur end You can test it by doing this in Lua:
print(string.format("%X", XOR_CS(tohex("01 03"))))
You can put in whatever you want in the tohex call (will be interpreted as a series of hex bytes), or remove the tohex call and put in your own string, but using tohex is easier to see that all the input is being applied to the CS.
RyanE
 

First world problems... 
RyanE

At that point in time, *all* drivers were written only in C++ (the part on the controller, C# for ComposerPro, but wouldn't affect controller performance).
If you have a lot of drivers these days, many of them are using more CPU due to them being interpreted Lua, which, although it is very efficient, it's not C++, and 3rd-party devices may not have as efficient APIs as Zigbee (may require polling or responding to frequent async messages, etc.).
I personally think what affects CPU needs are: 1) Number of 3rd-party DriverWorks device drivers (written by Control4 or 3rd parties), 2) Number of touchpanels or other UI devices (which also require a lot of data and CPU).
Guidelines are of course not hard and fast, but I think *neighborhood-wise*, the recommendations are not unrealistic, but I think size of controller is even more driven by the number of IOs needed than the CPU of the controller.  Bigger projects need more audio outputs, IR / Serial, and Contact/Relays.  *Really* big projects need both.  I've got a CA10 + 3 EA5s (and several I/O extenders).
RyanE

Yeah, we upgraded to unlimited data ($30 more a month) when the kids moved out and we started doing AirBnB in the basement.
RyanE

First world problems... 
RyanE

First world problems... 
RyanE

First world problems... 
RyanE

I took the plunge and purchased a Core5 and a cheap secondhand EA5 to replace my 2 HC800s today… not cheap!
As both of my systems already have CA10s as directors, I am not going to see much improvement but I will get an extra stream of audio and a 4K OSD…
As I only have a 4K projector at one house (and that was not the house with the HC800s), I now have a fairly complicated job of swapping controllers between houses etc… thankfully I use the same dealer for both residences!

Lua runs out of a shared library loaded by Director, so the (Lua or LuaJIT) interpreter code is only loaded once, but every running Lua driver (one per driver *instance*) needs to keep it's own state.
Every DriverWorks driver has a Lua state object, which contains all of it's code, all of it's variables, all of it's current machine state global tables, locals, active coroutines, upvalues created inside of functions, etc...
If your driver is not actively running, it is not taking much CPU, but it is still taking memory for it's current Lua state.  Drivers also use other Director resources when they're not running, like timers, sockets, non-socket network connections, etc., but mostly, unless something is actively happening in the driver, it is not using too many resources.
Bad drivers (those that poll too often, those that have slow memory leaks by not freeing up Lua variables properly, those that eat up timers or sockets instead of reusing them (where possible), those that use language-based looping inside the driver for timing, etc.) are most of the problem, but even DriverWorks drivers that do not do any 'bad things' likely take more resources than a good-sized C++ driver, just due to the nature of running an interpreted language.
One other thing to consider is that every piece of data that a driver receives from Director or is sent to Director has to go through Lua's C++ stack, so the more data a driver is plowing through, the more CPU is required just to pass data back and forth from C++ to Lua.
Bottom line, if you have a lot of DriverWorks drivers, you probably need a more capable controller, but no, a driver that periodically sends an HTTP request (or does it on keypresses from the remote) is not going to use a lot of CPU...   
RyanE

That restriction was removed 

The advantage for me would be a mic close enough to me to use when the background noise is to loud. Often when watching a movie or listening to music, it is just to loud for my echo to hear me.

No there is not a room limit

At that point in time, *all* drivers were written only in C++ (the part on the controller, C# for ComposerPro, but wouldn't affect controller performance).
If you have a lot of drivers these days, many of them are using more CPU due to them being interpreted Lua, which, although it is very efficient, it's not C++, and 3rd-party devices may not have as efficient APIs as Zigbee (may require polling or responding to frequent async messages, etc.).
I personally think what affects CPU needs are: 1) Number of 3rd-party DriverWorks device drivers (written by Control4 or 3rd parties), 2) Number of touchpanels or other UI devices (which also require a lot of data and CPU).
Guidelines are of course not hard and fast, but I think *neighborhood-wise*, the recommendations are not unrealistic, but I think size of controller is even more driven by the number of IOs needed than the CPU of the controller.  Bigger projects need more audio outputs, IR / Serial, and Contact/Relays.  *Really* big projects need both.  I've got a CA10 + 3 EA5s (and several I/O extenders).
RyanE

Personally, I find more value in the remote being able to do a voice search on the Comcast Xfinity X1 box or AppleTV (so you wouldn't need to keep around the Xfinity Voice Remote), although the plans are at some point (don't know if at release or not), it should be able to also send voice to the 'whole-home' voice providers.
RyanE

The SR260 has not been end-of-lifed.  I'd imagine if they continue to sell, they'll continue to get made.
If completely sales dry up, it would probably be EOLed.
RyanE

It went on Holiday.
RyanE

Yes.
The Phone / Tablet needs to be logged into the customer's Control4 account.
Funny enough, since I enrolled all the Halos in the booth, and forgot to clear out the accounts from my Android Phone, I got Chime calls while sitting on the toilet during the show... 
RyanE

This is all off topic...

Zero here (well unless you want to count the one that came in...without the actual remote in it 
(had a base though....) - but yes picky in wifi, dedicated 2.4 SSID (and no fast roaming) is required for sure.

Roku does not have a Voice API, and Control4 doesn't have contacts within Roku.  That is unlikely to happen anytime soon (although, of course, if a Voice API shows up, it would be fantastic).  The voice APIs in Roku are for the Roku *APPS* to receive data from the voice input of the Roku.
Snap One has not announced integration with Dish, but Control4 does have contacts within Dish, so I'm much more hopeful we will be able to make that work.
The price of the Halo Remote is not much more than the MSRP of the SR260 + the Charging Base, which combined was something like $440 MSRP, and value for money, the Halo remote looks to me to be pretty fantastic.
RyanE

I've had very few problems with my Neeos, but they definitely can be picky about wifi, and like to be assigned to a single AP, and don't seem to like roaming.
RyanE
 

Correct. Just like you didn't for a neeo. As long as your system is updated to 3.3.1 or later 

If the customer has a device already connected, it would be easiest to just use their device or have them walk through the first-time user experience.
If the customer does not have a device connected, you would need to login to their account on your device, so I assume you would need them to do that, and/or share their password with you.  The device *does* have to be on-site and physically close, since the device itself passes the credentials to the Halo remote during setup.
RyanE