I believe Photon chip is BM-09.
I think that this chip has Broadcom Wiced.
Broadcom Wiced has HomeKit spec (for Apple MFI Partners)
Broadcom has their own SDK&IDE for Wiced.
Assuming theses are correct, I wonder if Spark team has comments on these? What would be the appropriate way to access Wiced from Spark sdks, which IDE to use? What is the Spark point of view on these to guide developers?
The Photon module is the USI BM-09 module, with custom Spark firmware pre-loaded, and pre-provisioned access to the Spark Cloud
This features Broadcom’s BCM43362 chipset, which is part of the WICED platform
Broadcom WICED does have a HomeKit spec (for Apple MFi partners)
One caveat here… participation in MFi requires a special authorization chip from Apple which the BM-09 does not have. USI’s BM-11 module is very much like the BM-14 (in that it includes a u.FL and onboard antenna), but also includes MFi compatibility for Apple’s HomeKit spec.
The WICED SDK is entirely different from the Spark IDE and developer environment, and it’s likely that our firmware team will significantly modify the WICED libraries in creating the default firmware for the Photon. For now, the best way to access and modify WICED libraries is through the WICED SDK + IDE, since there may be elements of the underlying Broadcom firmware that we cannot open-source.
For the Photon (BM-09), it’s unlikely that we’ll be able to provide HomeKit support. We’ll investigate further on our end, since I know that USI’s BM-11 does include the MFi authorization chip. Stay tuned, but for now it’s not in our immediate plans.
Thanks for the update. I hope you’re able to get the MFi compatible chip in a future version, as a HK-compatible prototyping platform is high on my wish list. I would probably order at least 4 of them!
Yes the homebridge would be fantastic.
I have it running actually
Unfortunately they don’t have a way to handle the Particle Cloud API REST interface.
They do have an HTTP way of calling a service, then it should be a simple URL to call a function.
I asked on the Homebridge repository if they can consider the Particle as a feature.
Maybe also someone from the Particle community should have a look into it.
Hi @rudyvan. Glad that you like video. As suggested in Homebridge feature request I took their server and alternated HTTP accessory to accept not only URLs but also payloads for requests. This allowed me to provide access_token and any other function arguments with requests. It was implemented in a hack way so I am not ready yet to do pull request into Homebridge, but I have plans to arrange Particle as normal accessory where integration would be extremely simple. If you think it is needed for Particle, please take a part in conversation happening in your Feature request — https://github.com/nfarina/homebridge/issues/34
Old thread… but I use node-RED to connect my devices indirectly to HomeKit via openHAB. It also could be done directly using the contributed Particle node or using the MQTT node. Lots of good tips for integration on the openHAB forum, useful even if you don’t use openHAB.
Lukas Jezny developed an application for a Photon, in which he implements a HAP (Homekit Access Point) on the device itself. So, you don’t need a Homebridge or an OpenHAB server to control a Photon with Siri…
It works beautifully: You compile a sketch and flash it to any Particle device and then it can be directly paired with Homekit on any iPad, iPhone… Currently, you can only control the Particle’s RGB LED ON/OFF state.
I was hoping that Lukas would also show us how we could access Particle.function s and Particle.variable s from Homekit. But, fair enough, he apologised because he can’t make the time for it. Pity…
He shared also the Apple document explaining how to expand the functionality, but it goes over my head!
If some of you, professional programmers, would be interested to try and expand his work, I believe many Particle users would be very happy! I would…