RyanE

Alexa has a fairly strict timeout in terms of how quickly the controlled system (Control4 in this case) responds, and that window is right on the edge of how long it takes Control4 to start up a remote connection into your controller to send the command, and get the response back. It's something we've been working on in order to cut that response time down, but occasionally, depending on several factors, it can still timeout. It's likely not the KNX system's issue, as lippa mentions above, although the KNX Routing Gateway is still a better solution, and if you have a large KNX system and/or a large Control4 system, it taxes the Control4 system quite a bit less, and would likely be a valuable improvement if you wanted to pursue it. RyanE

The new driver, although official, does *not* provide significant features over the 'legacy' unofficial driver (or even an IR driver) at this point in time. The HC800 is a great controller, I'm glad to hear it's still working for you, and you have other options if you want to keep it running. RyanE

There is actually a technical issue with supporting the Apple Bridge on the HC800. It was debated internally, and the original idea was to provide it on both, but due to the technical issue it was cut from the HC800. It was *not* a sales / marketing decision. The HC800 was originally released over 7 years ago (January 2012), and is not being deprecated in the near future, although there are some features that will be released on the EA series and not on the HC series. Unfortunately, one of the first of those is the Apple Bridge support. Sorry. RyanE

You would have to go find where it's at, look up it's model number, and see if it supports multicast routing. Unfortunately, there are *so many* manufacturers and products, it's not something I can just tell you whether or not the gateway supports multicast routing or not. Some devices support it, but have to be configured to 'turn it on'. You may want to get a KNX expert (certified KNX Installer) in to ensure that it's the proper device, or if you're having issues getting it working. RyanE

Glad it's working out for you. If you have any ComposerHE questions, feel free to post them here. RyanE

You need to change all the devices' "KNX network" connections to point to the Multicast KNX driver. You shouldn't have to change any of the addressing in the drivers themselves, because the Group Addresses haven't changed. You *do* need a KNX Routing Gateway for it to work, and not all KNX Net/IP gateways are routing gateways. It uses the Multicast Routing Protocol, and is quite a bit better (IMHO) than the old KNX Network driver. RyanE

The real win is not having to do extensive ComposerPro programming. RyanE

There is a driver just for this purpose in the Control4 online database. I created it for my house, because it's annoying to smash your lock into the door jamb. It's called "Door Auto-Lock (OS2.9+). As you can see in the name, you have to be on at least Control4 OS 2.9 for the driver to work. You add one for each door (that also has a separate contact), and connect the lock relay connection and the door sensor connection. You then turn *off* the auto lock on the lock itself. The only downside to this is if the Control4 system is down, your doors don't automatically lock. It's an Experience Button driver, so it can show up on the UI, shows door status (Locked/Closed, Unlocked/Closed, Locked/Open, Unknown). The driver will lock on expiration of delay seconds, *after* the door is closed. If the door is opened and then closed, the timer starts again, so in my case (delay set to 300 seconds), if I answer the door, shut the door, and 4 minutes later, I answer the door again, the lock will engage 5 minutes after I close the door again. The driver has: 3 Experience Button icon sets (one red/green, one green/red, and one black). The red/green vs. green/red is because for some people, locked should be red, and other people think the locked state should be green. the ability to configure whether the Experience button UI allows unlock or not If not, it can be used to lock the lock when the door is closed, but not unlock the lock. a configurable auto lock delay, with a much longer delay than some of the manufacturers' locks. button bindings so you can connect the driver to keypads, and show door state with LEDs, as well as control the lock with the keypad button. events for Closed/Locked, Closed/Unlocked, Open/Locked, and Open/Unlocked. commands to Lock (if door is closed) / Unlock, and Enable/Disable, so you can program turning on / off the 'auto lock' feature. I use this when I have houseguests during a party, etc., so the door doesn't automatically lock. It works with any of the controllable door locks and requires a 'door open' contact installed (any kind). And it's all for the low, low price of free (plus dealer installation). RyanE

That is frustrating, sorry. I don't get it, either. RyanE

If WOL is working, but commands are not, one of these is likely the issue, since the output above shows the driver can't connect to the IP control port: The TV can't do IP Control The IP Control is not turned on for the TV The IP Address the driver has for the TV is incorrect Networking issues are preventing the driver from connecting to the TV. RyanE

Are they dimmable? What specific model number are they? RyanE

I'm unaware of any limitation of sending basic string and number types through those functions, not sure what you're seeing. RyanE

You are correct, SendToDevice tParams does not support nested tables. You must serialize the data for more complicated structures yourself, as you've found out. As far as returning the value from a C4:SendToDevice call, the documentation is incorrect. ExecuteCommand in a driver can't return a value, as it's called asynchronously from the other driver. You can send a synchronous call to another driver and get the return values back, but there are some limitations. 1) Instead of C4:SendToDevice(idDevice, strCommand, tParams), you use C4:SendUIRequest(idDevice, strCommand, tParams) 2) Instead of function ExecuteCommand(strCommand, tParams) ... in the 'receiving' driver, you use function UIRequest(strCommand, tParams), and you can return a string, but the string must have an 'outer XML' structure to it, due to legacy reasons. i.e.: return "<mydata>" .. myJSON .. "</mydata>" Note, this is synchronous communication, so you can't really wait for asynchronous data from another location (i.e. network, etc.) to come back to reply. RyanE

I know this isn't what you're asking, but it's been almost 10 years since Control4 upgraded from embernet to ZigBee Pro, and you're unfortunately likely to have a hard time finding embernet switches, since there's no downgrade path to get them back to embernet. It might be more productive to get a newer controller that runs 2.x, and upgrade your current dimmers/switches to ZigBee Pro. RyanE

In General -> Network -> Expert Settings, ensure that 'Power On with Mobile' is enabled. RyanE