Phidget SSR

Ah, brings back memories of my first homemade 8 channel controller built using a PC Parallel port and these hockey puck style solid state relays. These are not dimmable, just an on/of setting. The hobby sure has grown since using these.....
The specification indicates they are random turn on so I would think these would be dimmable. These are the cheapest hockey puck random turn on relays that I have found but they are still pricey. I am wondering if they would perform better / more realiably than SSREz type relays that I currently using.
I could be wrong but I believe the random part of the SSR is for when the SSR switches on and off according to the type of load applied and when the triggering voltage is present. For a motor or servo with an inductive load, you would use a random turn-on SSR like these as they switch on immediately after the circuit opens. When you are turning on and off LED with a resistive load, you use a SSR with a zero-cross turn-on as they switch on and off once the current hits a zero value. Zero-crossing relays don't always turn off inductive loads very well. I don't think this is what you are looking for in terms of dimming LEDs. The circuit is still either on or off, just at what voltage and when it is tripped. But I understand your though as it opens/closes as the voltage is increasing / decreasing, which could, in effect, look like a ramp up/down. You just can't control that ramp voltage.
The specification indicates they are random turn on so I would think these would be dimmable. These are the cheapest hockey puck random turn on relays that I have found but they are still pricey. I am wondering if they would perform better / more realiably than SSREz type relays that I currently using.
What kind of performance/reliability issues are you having? As far as I know you shouldn't be having any issues.
A dimmable output using an SSR works by delaying the "Turn-On" signal to the relay by a variable delay based on the desired output intensity.

A Zero-Cross Relay only allows you to turn it on within a specific window near the zero-cross point.
A Random turn on relay allows you to turn on the relay at any point in the AC Wave cycle and then turns off at the next zero-cross event.

That makes the Random-On relay dimmable.
I use SSRez relays in my show. I have to fix one or two channels every year. Not a good rate when there are only 60 SSR Channels in my show.
I have 12 mini-trees with 7 channels each, total of 84 channels. The controllers are homemade using Arduino Due. I have had channels that either don't dim at all or instead of dimming they start to blink. The SSR's are not all of the same build. I think some of them have Renard logos on the PCB. There are inconsistencies in the dimming level between the controllers / SSR builds. I might be able to compensate for this using a dimming curve in Vixen. I figured out this past season that some of my issues correlated to increased air temperatures. I was leaving the Arduino's powered up during the day and some of the channels stopped dimming. I switched to unplugging the Arduinio's after the show and turning them on just before show time and they started dimming again. This makes me think my issue is not with the SSR's but that the Arduino is slowing down due to heat. I was eyeing these phidget SSR's just to potentially get something more reliable with consistent dimming.
As you said, it does sound like the issue is the controller and not the current ssr's you have. Keep in mind, if you went the route of the phidget, you'd still need a controller to control it.
If it were me, I'd try and narrow down exactly where the issue is the control (I'm cheap and the phidget isn't).
I think I'd start by looking at the dimming inconsistencies that you are talking about. I'd locate 2 ssrs that are inconsistent from one another and note how they are inconsistent. Then swap the controllers and see if the inconsistency stays the same or changes. This should point you to ssr or controller.

On 2nd thought, since you said leaving them on can lead to issues that get resolved by rebooting, I'd suspect a possible code issue that during off times its somehow getting into an unknown state. For example, if some interference gets on the line and creates ghost data.

If you're interested in going this route, post more data on how the controller is set up and I'm sure you'll find you'll get more help troubleshooting it then you'll know what to do with.
If they're inconsistent, you might check the leakage current when it's supposed to be "off." Most TRIACS leak something, and if memory serves me right, the higher the trigger voltage, the more leakage you can expect.
Are you using PWM output? The use of just a pulse output leads to latching issues that get worse as you approach 70% on and under 30% on.
I am not sure what "Phase Cutting" means. Renard (and other) controllers dim in one of two modes:

Fixed Pulse width phase shift: Trigger the triac part way through the AC cycle at a point to get the desired intensity. The pulse width tends to be fairly narrow and is just enough to get the triac to latch. With LEDs. the current needed for the triacs to latch near the start and end of the waveform was not enough to make the triacs latch. This caused a lot of flickering and unreliable output with symptoms that varied by temperature, humidity, number of LEDs, leaves / people touching the wire (sound familiar?) that drove a shift to PWM Outputs.

PWM Phase Shift: Outputs send the turn on pulse starting at an appropriate time and keep the trigger signal active until just before the next Zero crossing event. This results in a pulse width that is variable in length relative to the total intensity needed on the output. This removes the minimum current requirement for latching and fixed many of the flickering issues (did not fix my squirrel issues) at intensities below 30% and above 70% of full intensity.
Do both of your described modes monitor the zero cross? I think my code is turning off the relays at the zero cross event and then turning them back on partially through the AC sine wave to get the desired intensity.
You cannot turn the SSRs off using a control signal. The Triac turns off automatically at the next zero cross point. The software must ensure that the trigger signal is "off" just prior to entering the zero cross point. Both models turn 'on' the SSR at some delayed (aka phase shifted) time. The important feature is when the SW turns "off" the pulse. For LEDs, the pulse needs to be turned off about 10us before the zero cross point. Then you get reduced flicker.
How are these implementations triggering just before the zero cross? My controllers have zero cross detection hardware that interrupts the Arduino.
My controllers have zero cross detection hardware that interrupts the Arduino. I would guess that the software could keep track of time between true zero crosses and try to turn the signal off just before.
I would assume your Arduino works like all the other implementations I've seen. The notification comes in on an input pin and the software reacts to it. At this point the software would do anything necessary for the the next half of the AC wave such as resetting the outputs, resetting the "timeslice" counters, etc.
Most of the zero-cross detection circuits trigger a few nano seconds prior to the actual zero cross point. That means the logic is easy to turn off the output and then start the timing logic to determine the turn on point.
When I was observing the behavior of H11AA1 circuit the leading edge of the zero-crossing signal was many microseconds before the actual AC crossing, perhaps upwards of 1/2 millisecond in advance.
In my version of the Renard controller, I measured the time between pulse start and pulse end to determine the approximate center of the pulse so I could predict the ZC point. That way I could be sure the signal wass off at zc.