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

The latency for the shelly should be low (with Chowmain driver) and not really noticeable in practice unless you have a bad wifi network, overloaded controller or possibly lots of interference on Zigbee. We always recommend Pro/Plus (Gen 2) or Gen3 modules if possible if you're purchasing them, as the protocol is more scalable and is far better (we don't need to test every device anymore, and just implement by capability) Also, we're pushing a new version tomorrow with some enhancements to button links tomorrow (for Gen1 modules) which may affect this case. In addition, a lot of memory / performance optimisation work has gone into recent releases (which will be mostly noticeable on slower controllers, or certain networks), so we recommend everyone ensures they're using the latest version. Particularly if you have a lot of shelly devices. Also, obviously, there's been a lot of feature improvements recently All of our drivers have a 90 day trial though. You can use to test with

Technically, chowmain light group can emulate CCT now too.. but you would need to test if its suitable for your use-case (as there are limitations to the emulation, and some limitations with the precision available too) But I agree, this all depends on the usecase

Honestly, I'd recommend the Shelly RGBW2 over Govee. Whilst it's not wired in, we have a lot of people using it, and in my experience they're fairly reliable (I actually use one at my own place) Andy

Worth noting that Google Play Games for windows is already in beta. And TPM in windows 11 is mandatory (so it can be kept secure too). Hence why I wouldn't be surprised if this is in response to Google swooping in, in the future

I'd start by checking to see if the laser is visible through the cable (don't stare at it). And replace HDMI.. Most of the time its the HDMI honestly. Sometimes the HDMI also isn't the full way in the port (or the fiber isn't) Take a look at Blustream otherwise.. https://www.blustream.com.au/hdmi-over-fibre-fve4k-kit

I just got that too. I use it all the time.. However, honestly, this arrangement with Amazon never made sense, and it's probable that Microsoft are going to use their own store instead or work with Google

You'd have to be more specific than network crashes..I'd start by loading a Linux live cd, and seeing what happens. Check also your network settings are set to dynamic IP. If you're running 3rd party av, Get rid of it (it could be doing stupid things). Etc There isn't enough information happening here.

Yep. Using outlets directly as lights was simply designed for convenience and was added after the initial design to speed up deployment as requested by installers. And it won't work for all outlet devices either. Auto setup will provision it as Outlets instead by default, and you can use the Auto-Setup Outlet Lights to link the lights. This is the recommended way (explicitly for energy monitoring). The lighting driver would be too complicated if I added the energy code too (the TPLink code is already fairly complicated, which is why it's taking so long to add new presets support). Andy

As @msgreenf said.. Also, whilst it might not break things in this case, DO NOT CHANGE THE Light Category! That does something different than you think it does (ie, it affects the communications, not the icon or anything else)

Gday sorry, what are you driver names for both types of driver. Don't delete any drivers.. they might be there for a reason Workaround for power State is because tplink reports old power information when polled for a short time after setting the power from c4. So we assume it's wrong for 5s. If you change that, in some circumstances the power State might be wrong. Don't change that unless chowmain tech support tells you, or power status flicks to the wrong state temporarily after being changed from c4 Don't select device from list. That's used for auto provisioning and is used to change the device it's connected to, and even then, we don't recommend using it unless you're changing it to a device with similar specs. If you select that, you might even break things. You should only ever generally use that once (and it has probably already been used)