Homekit + Arduino (?)

[marcodallago]

Hi I'm trying to create a relay board in order to switch on and off my home's gate. I'm using Arduino, I know the code of it. My idea is: Siri-> [ Hap-Node.js -> Johnny Five] -> Arduino (using Firmata) -> Relay. Is there an easy way to do that? Is there a framework that solve this problem? Inside [..] you can find the code that runs on a online server, so all the computational data are processed on a connected computer. Johnny five's aim would be only to send data to arduino (and of course tell him what to do depending on the instructions from Hap-node.js). Thanks for any help

[AdySan]

You can try ESP8266/Arduino, I got this to work a couple of weeks ago with MQTT messages being sent to the ESP8266.

https://www.instagram.com/p/6L7hbpEdT4/?taken-by=adysan

[marcodallago]

Yep, thanks for the reply. Actually I've also set up esp2866 and it is included in my project. Could you show me a code example of how to send mqtt messages to esp2866? The project works with blynk, but with homekit is quicker

[AdySan]

There's a bunch of examples in this library: https://github.com/Imroy/pubsubclient

On the HAP-NodeJS side, I was using https://github.com/mcollina/mosca

[AdySan]

I wrote a post about using ESP8266/Arduino as a HomeKit Accessory.

http://adityatannu.com/blog/post/2015/12/13/ESP8266-based-HomeKit-accessories.html

[marcodallago]

Thanks! I'll give it a chance ;) actually i found out that the easiest way is to run directly the program in raspberry pi, instead of having an external server that runs it for you. So I'm thinking about using raspberry pi 0, connected to the net with an esp2866. The relay board is connected directly to the pin of the raspberry pi, so that it is able to run other programs depending on the change of the status of my accessory. Thanks for the tutorial (very easy to understand) and the help btw ;) I'll let you know

[pieceofsummer]

@AdySan ESP8266 is powerful enough to be a native HomeKit accessory itself. There's no need to bridge it over node.js host.

[marcodallago]

yep, you're right. esp8266 as board can do that. But actually the easiest way to do it is with a raspberry pi, that can continuously run the hap server code. Moreover you simply need a wifi dongle to connect to the net, and there's no need of any setup.

[AdySan]

@pieceofsummer @marcodallago Yes, I know it's capable, and I'm really looking forward to using it one day in that way. ATM, more than one person (including Espressif) are already actively working on porting HomeKit stack to ESP8266. Not sure how much of that work will be open source, let's see.

[pieceofsummer]

@AdySan I highly doubt Espressif would be able to do it officially without breaking legal issues, because MFi requires to use an authorization chip (with Apple's certificate inside). Porting HomeKit stack itself is not really an issue, it can be done in a few hours or so.

[AdySan]

@pieceofsummer I tried to ask John Lee from Espressif about the details of what they're working on, but they wouldn't say much. Personally I don't care much for commercial products using ESP8266 + MFi chip, as long as it can be technically done, it should be a good DIY solution to play with.

About porting HomeKit stack, if it's that easy, why hasn't anyone done it yet? It's been ported to nRF51/52 but I've hardly seen anyone using that. I don't think there's any problem with ESP8266's popularity, perhaps HomeKit isn't as popular in the DIY world yet. The general trend being towards more open solutions like MQTT, OpenHAB, etc.

[pieceofsummer]

@AdySan well, using MFi chip would definitely increase the cost of ESP8266 boards, so it won't be as attractive for DIY solutions anymore. Probably it's a stopper of a kind.

Regarding the open-source amateur solutions, probably it's just nobody cares much about HomeKit (yet). I don't see any technical issues here, as all the cryptography used is quite simple and runs fine on ESP8266. There's definitely quite a bit of work optimizing the crypto speed for specific platform, but the proof-of-concept solution can be definitely done with existing public domain code, like reference C implementations of curve25519/ed25519.

[AdySan]

I wish I had the smarts (and time) to do it! Hackaday thought what I did was cool. But you're right, it's kinda under utilizing the ESP.

One vendor trying to commercialize their ESP based products actually did contact me because of this, Also sent me their product! They're been trying to get the amateur solution to work and apparently it is working pretty well.

[MagicCube]

I wrote a simple Arduino Homekit demo project connected via HAP-NodeJS https://github.com/MagicCube/homekit-server

Youtube Link: https://www.youtube.com/watch?v=rn5vwHkzutk&feature=youtu.be

[FradSer]

@MagicCube Cool project.

[HomeACcessoryKid]

I've made The Thing 100% ESP8266 native and it works like a charm. Enjoy this video: Demo HacK

[AdySan]

Great! I find that a little hard to believe...can you share some more details?

Sent from my iPhone

On Oct 16, 2016, at 1:07 PM, HacK notifications@github.com wrote:

https://www.youtube.com/watch?v=Xnr-utWDIR8 HacK

[HomeACcessoryKid]

So, I've used RTOS1.4.2 and encoded in C the same procedures as KhaosT has shown us. Abstracted the high level stuff to kind of an API. With the usage of Tasks and careful memory management it finally worked. Now ironing out the last bits like raceconditions when a disconnect happens during a pair-verify. I've got some 29k left for other code...

So, what makes it so hard to believe? Yes, it took me half a year of hobby programming (8h/week) but considering I didn't even know how pointers worked before, it also was no mission impossible.

HacK

[AdySan]

@HomeACcessoryKid That is amazing! I was skeptical because despite being possible, and projects like homebridge and HAP-NodeJS proving immense interest in HomeKit, no one's ported this to ESP8266 natively. AFAIK, even Espressif isn't doing it.

Anyway, do you plan to share your code at some point?

[Roman1us]

I'm trying to port HAP features to esp8266-arduino framework. I wrote homebridge plugin with connection over websocket(https) and abstract interface in c++. Also created some boards to control NeoPixels and thermostat. Testing and finishing plugin to release

[AdySan]

Well this completely eliminates the need for homebridge itself.

On Mon, Oct 17, 2016 at 2:26 PM, Roman notifications@github.com wrote:

I'm trying to port HAP features to esp8266-arduino framework. I wrote homebridge plugin with connection over websocket(https) and abstract interface in c++. Also created some boards to control NeoPixels and thermostat. Testing and finishing plugin to release

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KhaosT/HAP-NodeJS/issues/173#issuecomment-254339072, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtdatNsupQ8oi-yggIBWrd_t23u_xGGks5q0-f-gaJpZM4GtZ18 .

[HomeACcessoryKid]

Hi @Roman1us, Is yours a native esp or does it require the homebridge on RPi?

[HomeACcessoryKid]

@AdySan, I know, when I started earlier this year, I was like wondering if my search skills were getting rusty, how come no one made this already?? But over and again, it always ended with someone using KhaosT code on a RPi and then an ESP as a mere led-driver...

Anyway considering that when I started this to learn how to program a microcontroller (which I did ;-) I had no idea I would have this 'unique' thing now. I'll give it a month or so to see if someone is interested to buy my stuff, !disclaimers apply! If not, I'll probably publish the full code on github for all the world to go crazy...

If you have ideas how I can make a little (or a lot ;-) on the side and still share with the community, please let me know...

[Roman1us]

Hi @HomeACcessoryKid All works with homebridge on computer (homebridge<->plugin<->esp). On ESP use Arduino framework because lot of sensor's libraries supports Arduino.

[willrea]

@HomeACcessoryKid

If you have ideas how I can make a little (or a lot ;-) on the side and still share with the community, please let me know...

I'll give you a dollar. Really doubt you'd get anything, people currently using homebridge, etc will continue to use it without issue.

[aessig]

Hi @Roman1us, Where are you on porting HAP to esp8266, I'll be glad to help

[HomeACcessoryKid]

Hi everyone,

I've made the step of getting this released on Github. However I'm not too happy about all the issues that the licensing brings with it.

For now, considering I am using a crypto library that is GPLv2, I see little alternative but to release it under GPLv2. At the same time I see the node.js of KhaosT is Apache2.0 and I would like that those who actually build hardware devices will not be forced to publish their code as long as all they sell is the hardware (including OTA updates). Are there any licensing gurus here that could tell me if GPLv2 allows this? Would Apache-2.0?

Finally, is it worth having this objective in the first place?

On another note, considering GPL forces you to establish copyright, can it be done on a nickname, or does it have to be your real name?

Why did lawyers ever made programming less fun ;-( ?

HacK

[shawnlobo96]

Is it possible to perform all the cryptographic computation on the ESP8266? Long term and short term key generation and verification during pairing could take quiet some time on the ESP8266 (if I ain't wrong).

[HomeACcessoryKid]

@shawnlobo96, All crypto is done on the ESP8266. The SRP used for pairing takes a little under a minute, 25 seconds after booting, 30 seconds after the passcode has been entered. The verify takes 1.2 seconds which is about acceptable but would ask for an analyses of which part to write in assembly. The encryption/decryption of the messages after verify is hardly discernible, < 100ms. Bottom line, I think this is in the range of 'useful' considering iOS gives feedback during the 30 seconds after passcode.

[pieceofsummer]

That looks like too long. I believe SRP keys can be computed in 4 seconds each (at 160MHz during calculation), so entire pairing shouldn't take more than 10 seconds.

[       2ms] srv = srp_create("Pair-Setup", "123456789", salt, 16)
[    3954ms] r1 = srp_gen_pub(srv, srv_pub, &srv_pub_len)
[    3973ms] r2 = srp_compute_key(srv, srv_pub, srv_pub_len, srv_key, &srv_key_len)

[HomeACcessoryKid]

Then maybe I am using a not so good crypto library. Once we have the code on GitHub, we can see if this can be improved on. Meanwhile, I'm worried that using GPLv2 enforced by that crypto library will not allow us to move to MIT or Apache license later on. Would people prefer I spend some more months switching to other libraries or maybe define a crypto free code base under Apache2.0 or ...? Please help answering the questions 4 posts up?

[pieceofsummer]

Not sure about GPLv2. I use mbedtls, which is Apache 2.0 :)

[HomeACcessoryKid]

Hi Alexey,

I see you added some details to your speed evaluation. I already contemplated running 160MHz during this stage, so you can consider that my speeds can be doubled. When you say that you 'believe' these steps can be executed in this time, did you actually implement this in the ESP8266?

But actually, this is not of great importance, because we can consider the current performance 'usable' and if we optimise in the future, that is just luxury.

[pieceofsummer]

When I wrote 'believe', I somewhat recalled approximate numbers from the past experience. Then I added actual measurements from ESP8266 :)

[HomeACcessoryKid]

I have done some more reading in the swamp of licensing.

Consider section 6 of GPL3 bothers to cover my question regarding a device vendor having to give up his/her right to keep his/her modifications to him/herself if all he/she does with it is distribute it in hardware, not as software. This implies that GPLv2 does not have such restriction.

Can anyone confirm this is correct? https://www.gnu.org/licenses/gpl-faq.html#Tivoization

[HomeACcessoryKid]

More on the licensing choice

I now see three paths considering that I need to improve the crypto library slightly anyway

1. issue my code under GPLv2 just like my crypto library which is GPLv2_or_later
2. issue my code under GPLv2_or_later just like my crypto library
3. issue my code under Apache2.0 while crypto library becomes GPLv3

Option 3 has the advantage that later on we can swap out this crypto and get all Apache2.0 code

Do people agree Apache2.0 is preferred or GPLv2 or GPLv3 is better for the ESP8266/HomeKid

I'm still needing to know if establishing copyright is allowed under a nickname.

[echamberlain]

@HomeACcessoryKid If the GPLv2 license is used, then generally the source code must be published. Tivoization was an issue, because TiVo was publishing the source code, but there was no way to load changes on to the hardware, and getting it to run, without TiVo digitally signing the code first. GPLv3 was created to address that issue.

You are probably better off finding a crypto library with a more friendly license, like Apache, BSD, or MIT.

As to your copyright questions, copyright is established when the work is created. One doesn't need to do anything special to assert copyright. You can probably get away with publishing it under a nickname, authors have been doing it for centuries, but I'd check with an attorney first.

[FradSer]

@HomeACcessoryKid 👍

[er-ck]

@HomeACcessoryKid Any news on the licencing?

[HomeACcessoryKid]

very slow but I'm pretty sure you can all enjoy the christmas holidays with a nice thing to explore :-)

[HomeACcessoryKid]

Hi all,

wrestling with GitHub: how does one make a repository that delivers files in different regions of an existing directory? In this case I want to deliver stuff in the ESP_RTOS folder that came from Espressif It should go in the directories "include", "third_party" and one of my own. I have tried to use my own folder and then symlink stuff but that does not work at compile time...

Any advice? I would like to deliver the code today... HacK

[HomeACcessoryKid]

for those that didn't get the news yet...
ESP8266-HomeKit

Enjoy

And for those interested in Arduino style, I've created a focus point:
Arduino-HomeKit

Good Luck