[BRAINSTORMING] CoRE Integrations - ideas?

Coming up in Beta Milestone 3, we’ll have a last batch of new features added, before moving on to CoRE RC (release candidate). Meanwhile, I’m trying to find out what other cloud-to-cloud integrations CoRE could bring on the table. I am thinking of other ecosystems like IFTTT.

And I’ll start off with one idea, though I haven’t even tried to figure out if it’s possible (everything is possible, anyway):

  • Wink Integration - is this needed/feasible?

Please feel free to brainstorm below. Brainfarts are welcome too, though not really necessary he he

Thank you

1 Like

IBeacons! :sunglasses:

SmartRules can do this, but it’s only available for iOS.

For a more general ST approach, see:

1 Like

Okay then, on to the batmobile. Which way? Is that a hardware device? Does the i imply iOS only?

1 Like

Are there several companies producing this? Or is it only one? If more, do each produce their own base station? Which would be the most needed one for ST? Sorry for my ignorance, I vaguely know what the iBeacons do, but never needed one. My iPhone presence works despite all horror stories here :wink:

1 Like

I’m not sure if this would be a CoRE specific integration or a general ST integration, but the ability to control TP-Link smart plugs would be amazing with how cheap they are.

I think that should be a smartapp manager + dth. Proper way to do it.

1 Like

The standard was first defined by Apple but it now works with android, although not quite as well. There’s also a new android standard called Eddystone. Most of the hardware manufacturers now make their beacons so they can be configured for either the IBeacon standard or Eddystone.

The usual metaphor for an ibeacon is a lighthouse. The beacon is always transmitting, like a lighthouse always sends out a light whether there’s a ship there or not. It doesn’t expect a response. The content of the message is just the beacon ID.

So now you need receiving station software. This could run on the phone or run on a tablet. At my house we use it on a tablet which is always plugged in. So at my house it is the Beacon it comes and goes and receiving station that stays stationary. The receiving station recognizes The Beacon ID and then decides what to do based on that. So the IBeacon itself is really stupid. That’s why they can be made so small with excellent battery life. It’s the receiving station program that has the smarts.

Anyway, CORE doesn’t need to be a receiving station. Most receiving station software is capable of sending an HTTP put. So it’s easy to send it to the IFTTT maker channel, or, as Dave glass showed, to a SmartThings end point.

If you want to play around with them yourself, I recommend the Estimote beacons even though they’re expensive and the Beecon plus receiving station software from beacon sandwich. But if you want to go cheaper, radius networks is a good choice.

Read the thread I linked to and you’ll get a lot of information. :sunglasses:

One of the best things about beacons is that the better ones can be configured to change the transmission strength (how powerful the light is in the lighthouse). By dialing it down, you can set the detection zone to a much smaller area. For example, I have mine set so that I am not counted as “home” until I get to the wheelchair ramp at my front door. The detection area is about 3 m.

We were discussing earlier today that a beacon could be used for somebody who lives in a multistory apartment building and doesn’t want to be recognized as being “home” when they’re down on the street level. Beacons are perfect for that.

So what core would need is the ability to process The notification from the receiving station software that the beacon was either within range (home) or out of range (away) but for multiple regions.

Also, note that every beacon has a three-part ID so you can distinguish between an individual beacon and a zone of multiple beacons.

So let me make sure I got it, you install that app, you buy some iBeacon compatible devices (the light towers in your metaphor) and then the phone can send a HTTPS request to a ST endpoint whenever you come into or leave the “sight” of any of said devices. The HTTPS message would contain which beacon (which could translate to a zone or room) and obviously, the owner of the phone which is the user. Is this correct?

Could this be built in a Manager SA and DTH? Each person/software being the device, while each beacon being the location of that device. I am thinking, a DTH with a “location” attribute that can change to “away” or any of the ibeacons, whatever name you give them. Then you could use them in any app. Alternatively, have CoRE directly talk to Beecon (receive HTTPS requests from it) and provide those as conditions. I’m more inclined towards the SA+DTH approach. I can build that.

First paragraph, yes.

Second paragraph, you’d have to ask a coder. :wink:

I will look into this. I think it could go both ways:

  1. Person DTH - with location attribute that shows where the person is - if you have several short range beacons around the home
  2. Zone DTH - with list of people present in it

Looking at the Estimote iOS app - would their app work with any iBeacon devices, or just theirs?

I don’t have a cloud to cloud suggestion unless that other cloud is a tool in which to build pistons with a web browser!


Thanks for everything you’ve done @ady624


Remember that beacons are used two different ways.

  1. The Beacon stays put. The person with the phone walks close enough to the Beacon to receive its signal.

  2. The tablet stays put. The person with the Beecon walks close enough to the tablet so that it receives the Beacon’s signal.

In my case the beacon is affixed to my wheelchair. My housemate keeps one in his backpack. Some people put one in the car glove compartment. And some people wear them:

The Estimote receiving station software is designed to work best with estimotes. That’s because they have a whole bunch of fancy features, including additional security which is not available with other hardware.

I made the Estimote software see a simulated ibeacon from my mac - will look into their API to see how I can send info to ST.

Yeah, the role of the base and receiver can be either way, with any one fixed and the other one mobile. The fixed one should be the room, the mobile one the person/pet.


Ummm that can be done, but that’s going to happen in WebCoRE - oops, said too much.


Seriously @ady624, this is ridiculous… you committed to this and you never delivered it. It’s been a full two minutes and NOTHING.

Perhaps you can give us a weekly update thread to regain our confidence. I’d like to see a post mortem as well.


We need to push the update to CoRE first, then we’ll talk about the possibility of maybe having a chance at attempting to probably try WebCoRE. Problem is, you will only be able to edit pistons on the web, not in the ST app anymore. Either way, I have a plan. Which includes all your dreams. Duplicate, export, import, share, templates, etc. But let’s get CoRE out the factory door first.


You know, you always have to leave some stuff out for a sequel…


This is like the best news ever for me. I’d opt to never be able to build on my phone in a heart beat.

The more I think about this, the more this is something nobody sane will pass up.

If you can import/export, you can essentially backup and restore your logic. This would make me abandon all other apps I possibly could, there would only be a few edge cases - simply for the ability to backup/restore at will. Heck you’re practically building 80% of ST’s migration tool for them at that point.


WebCore, yes!!!

Wink could also be nice there are a few things that only work with wink.
Plus maybe it could make the wink hub usable for somthing like a signal extender.

One thing i would realy like is support for the Samsung SmartCam HD Plus
This realy needs a DHT but maybe somthing could be done with the smartcam app.

Thank you for everything you have done!

1 Like

The smartcam calls for a DTH. Outside CoRE’s scope. I am looking for a more… device-less cloud, the likes of IFTTT. Maybe tasker?