Andrew luecke

Possibly network loop if they're all hardwired

RS232 Matrix switches are generally easier. But, if you want to do it properly, its not a quick job depending on the protocol. But either way, you must be a partner or integrator to develop the drivers

G'day, Honestly, it sounds like you may require more prerequisite knowledge required to develop a driver (a lot of background knowledge is required, especially for things like lighting drivers). There is no easy 1-page pdf (especially since you'd definitely want 2-way). To put things into perspective, before I worked for Chowmain, I spent weeks learning to write a CBUS lighting driver, and it still wasn't completed (and this was with a lot of previous reverse engineering / development background). In fact, when i started working here, we mostly scrapped the majority of the code too (and it turned out, I was further from completion than I thought). And, a lot of small things I would have missed without Alan's insight and mentoring. All of our lighting drivers we've written recently are thousands of lines of code (Shelly is probably our biggest, and the whole driver is well-over 10000 lines of code, although, not all the code is related to lighting, but a lot of it is) My recommendation would be to contact the manufacturer, and get them to contact us for a quote honestly https://chowmain.software/for-manufacturers/request-quote . Otherwise, keep in mind, a lighting driver takes months to develop in full sometimes. These days we can finish

G'day before anything, do you have a beam sensor installed?

It's a global/Roku Firmware issue, and isn't actually an issue on Control4's side. Roku likely haven't deployed/completed the fix yet. Other platforms are also affected. Once deployed by Roku, it should start working again and no action should be required by yourself or your installer

Does that still matter though with 802.11k? As i think it provides neighbor reports with received signal strength?

Very little is gained by blocking Control4 honestly, and it's simply more likely to cause issues when troubleshooting

Any chance you can contact our support? If you're using V1 drivers though, it could be worth upgrading to V2 first https://chowmain.software/for-integrators/technical-support

I usually took a photo of the kitchen (especially because some of these houses have kitchenettes). And sometimes I would also filter the picture to make it slightly darker or lighter

This shouldn't affect anything. We don't update the initial state until it is confirmed actually, so a flood state should only be received if there is a flood. It could be worth checking the flood sensor firmware is up to date too. I do recall seeing this issue with some old firmware though Otherwise, can you please lodge a support ticket: https://chowmain.software/for-integrators/technical-support

On the old h&t, it gets updated every 0.5deg change I think for temp, or every 1% humidity change. And, I know in the past Shelly devices also used to check in to the cloud every 12hrs too (so the polling is dynamic) I'm fairly sure the plus would be similar.

Shelly H&T plus uses E-Ink for display: https://www.shelly.com/en-au/products/shop/shelly-plus-h-and-t

Might be best to speak to Shelly to see what they suggest for your application, as they have lots of products (and probably even more unreleased ones).

E-Ink is persistent (so not sure what impact it would have, as E-Ink is highly efficient, and will remain even with no battery. In fact, when I first opened ours, I was trying to peel the screen off because I thought it was a label, before realising). I don't believe so though, but could be worth messaging the shelly team to confirm. I suspect the impact would be fairly low though anyway

Gen 1 devices NEEDS to use the webhooks, so they're unavailable, and will get overwritten Gen 2/3 Devices (like the plus/pro/gen3), I don't believe we touch the webhooks at all, because we use the outbound Websocket channel instead for realtime feedback instead