Particle device plugin for Homebridge


#21

Hi thanks for your reply. I think I sorted this out. I changed to use just {STATE} in the config.json and changed my sketch to convert to in first before I check using my if statement. It seems to work now.


#22

Scotsss don;t know if this is still a problem for you, but I have found the plugin adds a trailing “}” to the args when you use the “{STATE}” keyword.

I suspect this is not a problem for the example firmware because the trailing “}” gets dropped when the arguments are read in.

This line >> sscanf(szArgs, “%d=%d”, &index, &value);

In my config.json I dropped the trailing "} " and it appear to work, although I am unsure why. Suspect this is not intended behavior but it works for the moment.


#23

Great! Homebridge works very stable and reliable now,
Switching lights ON and OFF with Siri has no secrets for me anymore.

But now I’m trying to explore the communication possibilities in the other direction:

Reading sensors

From @krvarma’s sample “config.json” file, I want to make this “device” (or “accessory”?) work:

               {
                    "accessory": "ParticleTemperature",
                    "name": "Room Temperature",
                    "deviceid": "222042000b47348882313031999",
                    "type": "SENSOR",
                    "sensorType": "temperature",
                    "key": "temperature",
                    "event_name": "tvalue"
                }

And I read @krvarma’s explanation:

Based on this, I tried various combinations of Particle.publish commands, such as:

  Particle.publish("tvalue", "key=" + String(temperature,1));


But the temperature value shown in the Apple HOME App does not change: It shows 20° continuously…

Any experience with this somebody?

:wave::older_man:

Edit: I now found the correct syntax:

  Particle.publish("tvalue", "temperature=" + String(temperature,1));

All works now!
Thanks
:hugs:


#24

Strange! I was experiencing the opposite:
The switch function worked quite simply but I couldn’t make the temperature reading work.
See my previous post.

I found now that my syntax for the Particle.publish command was wrong…

Thanks for the help!
:wave::older_man:


#25

any updates on adding a garage door for the particle relay shield ?


#26

I recently forked this code, and have begun adding support for GarageDoorOpener service. In the process, I’m refactoring a bit to use the particle-api-js library, which I think makes some of the Particle cloud API bits more clear.

One minor roadblock I’ve run into is that the current code assumes that there will only be one Characteristic related to a given service, and its value is tracked via the ParticleAccessory::value property. However, the GarageDoorOpener service has three required characteristics: CurrentDoorState, TargetDoorState, and ObstructionDetected. So in my current work-in-progress (which followed the example of the existing SENSOR services), the setting the initial default values and the event handling of state updates winds up stomping all over itself.

So my next step is going to be to create some sort of generic way to register each service’s characteristics, and track each value along with that that characteristic.

Once I have that working, it should lay pretty good groundwork for being able to handle just about any kind of service supported by HomeKit (I hope).

I’ll post updates when I make some more progress. And once I have the GarageDoorOpener bit working, I’ll link to my repo, even if the code is still a bit messy.


#27

After thinking a little more about how to support service types and characteristics in a more general way, I’m realizing that this will probably end up being a pretty heavy rewrite rather than just a refactoring… The way things are now, each new service type that you want to support has to be explicitly added to the code in a few different places. But I feel like it should be possible to handle any service if we can just get the right information mapped between the homebridge platform config and the Particle device functions/vars/events.

I feel like all the pieces are there, we just need to find a way to balance ease-of-configuration with open-endedness. This will probably end up with a slightly more complicated config on the homebridge side, but I think the flexibility will be worth it.

Right now, I think the config might end up looking a little more like this:

{
    "platform": "ParticleServices",
    "name": "Particle Services",
    "access_token": "<<access token>>",
    "devices": [
        {
            "device_id": "<<device id>>",
            "service_key": "GarageDoorOpener",
            "display_name": "Left Garage Door",
            "characteristics": [
                    "Current Door State": {
                        "alias": "cds",
                        "default": 1
                        },
                    "Target Door State": {
                        "alias": "tds",
                        "function": "toggleRelay"
                    }
                ],
            "event_name": "left_g",
        }
    ]
}
  • service_key: This should match a service property name from HAP-NodeJS HomeKitTypes.js (AKA, homebridge.hap.Service). E.g., Lightbulb, Doorbell, HumiditySensor, etc.
  • display_name: The name that will be displayed in the HomeKit app. I’ll probably let this be optional, and create a normalized name from the service_key, if necessary.
  • characteristics: An array of service characteristic info. For read-only characteristics, this will probably be optional, though an alias can be provided.
    • alias: The alias should be useful to provide shorter names, since memory can sometimes be at a premium on microcontrollers.
    • default: Lets you set a default value that a characteristic should have at startup.
    • function: For writable characteristics, the function property specifies the Particle.function() name to call when HomeKit needs to give the device a state update for that characteristic.
  • event_name: This will probably default to a normalized version of display_name, but this property will let you override that. The main reason for an override is the same as for the alias names of characteristics. (maybe I should name it event_alias?)

The Particle device will send events notifying value changes for characteristics. The value of these events will be a string that will probably look like {Characteristic Name}=somevalue, where {Characteristic Name} could be the full name of a characteristic or an alias. E.g., the Left Garage Door device could send a left_g event with value "cds=2" to inform HomeKit that the Current Door State value has changed to 2 (which indicates a “closing” state, according to the HomeKitTypes definitions).

I’m not positive if I’m going to stick with this completely. For example, I’ve debated about whether to use events in both directions (PubSub using Particle.publish() and Particle.subscribe()) rather than using Particle.function() for sending state changes from HomeKit to the device. I’ll just have to see if that would actually make anything easier or not.

Anyways, these are my current thoughts. Feedback welcome.


#28

Just an update for anyone interested. I’ve been working on this off-and-on, here-and-there as time allows. But I’ve been running into a problem where when I trigger my garage door relay function, it works the first time, but the second time, my homebridge plugin throws an error saying that the remote function doesn’t exist (“but you just called it successfully a minute ago, you stupid machine!”). I think this might be due to the node-hap module which underlies homebridge using once() on the callback function when setting a characteristic value. But I haven’t had time to properly narrow that down yet.

On the bright side, I think some of my ideas here for being able to handle arbitrary services defined by HAP, with just a little supporting info in the config file, does appear to be doable, based on what I’ve done so far.

I’ll share more as time allows.