@Emil I am sympathetic to the difficulties of effectively communicating product complexities. These implementation details you provided are interesting to me personally, but they are not particularly helpful to an average customer. It really feels like y'all have not carefully considered the types of questions a customer new to any of your products might ask. e.g. "I have/am interested in this product; does it have this capability?" or "I already have a Flic Button, can I do the same things with a Flic Twist?" Customers expect a certain level of consistency between different products from the same company. When you fail to deliver that consistency—and you do not effectively document the differences—it leads to frustrated customers.
The product matrix on the Twist product page comparing the Flic Button and the Flic Twist seems like a good place for some of this information. You already have a "Compatibilty" row in that matrix where you could explicitly list "Flic For Mac app" in the Flic Button column, and omit it from the Flic Twist column.
In the Flic For Mac app itself, on the "Add Flic" page next to the Flic Button illustration you could show a picture of the Flic Twist encircled by the crossed out sign.
Meanwhile, the Flic For Mac app page does not explicitly mention that it cannot configure a Flic Hub. That seems like a good place to mention that, especially when it is perfectly reasonable for a customer to assume that it can. Maybe add a feature matrix somewhere comparing the respective capabilities of the Android, iOS, and Flic For Mac app?
@amir I strongly disagree that the battery hatch comes off easily by simply pushing the tip of a screwdriver towards the center of the Twist, especially with the typical angle of a small flathead bit. There is a certain finesse to it; I have to "dig" out the hatch after releasing the catch. Maybe if you happen to have exactly the correct size implement, it would be easy. I have seen a lot of battery hatches over the last half century, and regardless of what design constraints you may have had with the Twist, there must be a better way to have done this.
Mine arrived today and I'm hugely disappointed with the complete lack of integration with HomeKit. I understand the issue that HomeKit does not support dimmer controls, but why do you not expose the click functions, to mimic the original button functionality? The suggestion below to expose the 12 selector are 12 individual buttons to HomeKit also makes huge sense and should be considered.
I have a Sonos system I cn use these with but can only control the volume and select native Sonos playlists. I only use the Sonos to access Apple Music playlists and radio stations, so cannot use this until those functions are supported.
You website is still describing the twist as offering "Effortless integration with your existing smart home ecosystem". How can you justify such a statement when it clearly does not work with HomeKit, unlike the swarm of existing flic buttons I am already using?
I have to say, I’m having a little difficulty squaring “this isn’t compatible” with the way this device was sold. The Twist was marketed as being “wildly configurable” and has multiple instances of “change volume” all over the Kickstarter page. The FAQ also mentions that “all Flic products are compatible with each other” and that the Flic Hub LR (a product I had to spend extra to purchase as an add-on following the update you guys sent on 2/20/23) would allow control of “your legacy infrared devices.” If I’d known this wasn’t going to be the case, I would have canceled my pledge, gotten my money back, and started looking for another solution.
@Emil I hate bluetooth. It worked fine from another phone, so I removed the hub from my primary phone and re-added it. Still didn't work, so I cycled BT on the primary phone, connected with no problem. sigh Not sure why I didn't try that before. Thanks for the pointer! (Taking logs reminded me how awful BT is)
@Emil How often is the settings UI collectively opened that this traffic could genuinely be a concern? This could be a super lightweight request, even just an http HEAD method to a CDN cached response that includes the version in one of the headers.
But let's say that even this traffic is too much, and you must avoid any network activity on Settings load. As soon as the "Check for New Firmware" button is pressed on the settings page, you could initiate this version check call to get the most recent version number. The next page should tell you either 1) that a new version is available and ready to be installed with an "Install" button (also showing the current version, the new version you will be installing, and a link to the release notes), or 2) that you already have the latest version with a "Back to Settings" button (e.g. "4.2.13 is already the latest version"). If there is a network issue, you could report that here with a "Retry" button.
If you are already checking and automatically updating the firmware every 24 hours, that information should be shown in the interface, too. Maybe an info button next to the "Hub Version" on that settings page that explains this. Ideally you would also show a log of the last N firmware updates, or the timestamp of the most recently installed update and link to its release notes at the very least.
@Emil that is great news! Glad to hear it.
BTW, I received my order yesterday and I must say I'm impressed by the build quality. You guys really did a great job. Can't wait to have it all properly setup.
The Philips Hue hub is discovered using mDNS on the local network.
Some debugging tips:
I guess you tried power cycle also the Philips Hue hub?
Try if the Hue hub can be found using our Android and iOS apps, without being connected to a Flic hub. That should help figure out if the problem is with the network connectivity on the Hue hub or the Flic hub.
You can for example use the app Service Browser https://play.google.com/store/apps/details?id=com.druk.servicebrowser to see if the Hue hub can be discovered on the network (look for _hue._tcp).