I have hours and hours  in to SIMPL with a new Sony STR-AZ7000ES.

Did the whole CCD thing, with True Blue, etc.  Could not get it to work.

Tried STR-ZAxx 1.1 (with Newtonsoft.Json errors, whatever that means).

 

Am I really resorting to IR for this thing?! 

 

Is it Crestron or Sony?!

 

Our RTI programmer had zero issues with same unit...2 minutes to get it going.

 

SMH

Honestly, never use CCD's. The protocols for almost all these residential devices is easy to implement. CCD's introduce more issues than they solve.

IR is still king...

On Wed, Nov 6, 2024 at 07:28 PM, markcrestrongroup wrote:

Is it Crestron or Sony?!

It's the digital age!...

 

I've been using the STR-ZAxx 1.1 for 7 years and it works great with these caveates:

 

And yes CCDs are trash!...

I guess I already posted it!!  Go to Files Section and search it if this link doesn't work...

 

Thanks so much for the .clz file and info on the STR-ZAxx 1.1 module.  This worked great! (Except for volume feedback, as mentioned).

So very appreciated!!!

 

I was arriving at your and other's following conclusions as well, after hours fighting with this:

 

"And yes CCDs are trash!..."

 

This might make me unpopular…

 

I do fell the pain of losing hours of unbillable time - we’re an integrator too, as well as having similar experience in developing CCD drivers for various boxes… but ;-)

 

CCD as a concept (especially the new model called “entities”) is - IMO - a good thing.  That doesn’t mean people (including the mothership) always write /good/ drivers though, just like there are many bloody awful custom drivers out there.

 

I get that some programmers don’t like the fact that they can’t crack open the driver and “tweak” things, but that’s not always the answer either - ideally a driver should do its job properly and, if there’s a bug, it should be fixed in reasonable time (the idea that code has been “lost” is ridiculous - I suspect that is, at worst, laziness or, at best, an excuse to avoid releasing code).

 

Sorry for going on - but I just wanted to defend the /idea/ of CCD in general.  That’s not to be mistaken for me defending crappy drivers or even a lot of the CCD SDK design - it works, but you need to have Harry Potter level skills to get it to work at times!

 

Ultimately we all use the best tool for the job - for some that may still be a (decent) CCD, and that’s what we aim for.

 

Oliver - Ultamation

I will say I started using CCDs reluctantly for the first time for this exact AVR on a current job where we have four of them. I am always keen on using 232 over IP control as it (almost) always just works. So after dealing with trying to get the quirks of using CCD working in my program which I eventually did, there was some flakiness of the serial CCD module for these AVRs. Volume ramping was garbage, input commands would work half the time, and the Zone Module was completely useless. Yesterday I switched over to the IP CCD and they all work perfectly now. I wonder if my issue had to do with using 4 serial modules and how they dont route directly to a com port you have to use the Packet Transmission, and all the signals just get jammed up going out of that module and dont always get thru.  

 

Also dont like they dont even follow Crestron's best practices of only polling when in use. Four of these things and they just flood debugger constantly. They have a Connect signal but no Disconnect signal. But if you open up the UMC there is a Disconnect signal that is not passed to the argument definition. Yet another example of Crestron saying "Do as I say but not as I do"...

First, Ollie you will never be unpopular!!

 

The basic concept for CCDs is not a bad Idea, but my Issues with CCDs for Custom Systems are:

- Crestron's implementation (the only relevant one) is poorly implemented

- Lack of transparency - What does this thing actually do?

- Additional management/back-up of processor-loaded files. This is a general problem beyond CCDs as well

- IMO, why do I need this vs a properly programmed UMC? How often does a system change hardware (TV, SRC, AVR, etc.) after initial deployment? not often for me. And even if a TV gets swapped or a change from Comcast to Fios, with a proper frame-work and UIs that are programmatically controlled by it, this change would be nominal.

- Source Code...  I'm arguably an OMA (Old Man Analog!) who comes from a world with only UMC/S+ code historically. modules with these either work or you customize/fix them and save them for use. Regarding this Sony issue, If Crestron could give me the source code (apparently they don't know where it is...) it could have been updated in minutes and saved for the AZ series and we'd not be wasting time with this conversation.  If it was a UMC/S+ module we'd already be done...

 

For those interested, I posted a test program with the ZA v1.1 and external code to deal with the Volume FB. not elegant but functional...

Hi Chris,

 

Thanks ;) and totally get where you’re coming from on the “fixing broken stuff”

I’ve also never been fully convinced by the runtime/reboot change of drivers in SIMPL systems - the extra baggage for managing this outweighs the benefit.  It’s a cool marketing message, but just not very practical.

 

However… beyond SIMPL it makes a lot of sense.  One driver that can (potentially!) work in SIMPL, CH, AVF, XiO gateway devices.

 

it’s a no brainier from Crestron’s point of view.  And, I guess, for SIMPL programming you have the choice to use either - it’s not like Crestron are closing the door on custom modules.

 

Ok - that’s me done on the topic :)

Agreed!!

To quote your mate Dyson "I just think things should work properly!"...Haha

Unified code/module absolutely makes sense. Just not when it hamstrings you because they didn't finish refining it...

 

OK, I'm done on this too!!...:)