Local Control options for particle proton board?

Not what I was implying.

An MCU (rPi or Arduino…) could determine which of the 100 “levels” has been selected, and use that to trigger up to 100 different local actions.

Is there an equivalent example of the cheese bulb hack somewhere? I’d prefer to just make something that smartthings thinks is a cree bulb.

Is the level of a cheese bulb locally controlled? I think for the sylvania strips only on off goes local. The dining is done across the cloud for some reason.

There are a couple, not many.

The Homeseer dimmer switch has individually addressable indicator LEDs, but it doesn’t run locally.

image

The Fibaro RGBW controller let you individually control each of four connected devices ( people often use this for sprinkler zones, for example) , but again, doesn’t run locally.

https://www.amazon.com/Fibaro-Micro-Controller-Z-wave-Strips/dp/B00P1N68FW

For the OP ( I know @Ryan780 knows this, I just want to clarify the details for @1SmarterThing )

Anything that spoofs anything will be custom code and won’t run locally unless it just runs out of the box with the other DTH, in which case you won’t have the other options for it when the cloud is available.

@ogiewon might have some ideas.

1 Like

What is a “cheese bulb hack”?

Sorry. On my phone. Cree got autocorrected (twice). Funny, it also corrected dimming to dining. I guess my AI overlord is hungry.

2 Likes

Also, you probably already saw this, and it doesn’t address the local operation issue, but just in case not, The following shows how one community member got the particle board working with smartthings very nicely. Not local, but I thought it might be of interest.

You mean something like this? The example sketch could be modified to run any custom code.

@Ryan780 brings up a good point regarding Cree firmware issues. You could disable OTA updates to resolve that issue, maybe.

2 Likes

Yep i saw that one. Thanks.

1 Like

I don’t think I’m doing a good job explaining. So here’s an example.

I have a smartplug that smartthings sees as a zigbee switch. It runs locally. I could connect that smartplug to a relay that goes to an arduino board such that when the zigbee switch turns on the arduino executes some code.

I could do that same thing multiple times (maybe 5 plugs and relays), connecting each relay to the arduino. That would give 5 bits of information that the arduino could use. (I could have 32 different programs executed on my arduino based on the state of my 5 switches). Each of these programs wouldn’t need the cloud to get started, as each switch is used by smartthings locally.

Thus, I was wondering, could I replace one of the plugs/relays with a zigbee receiver attached to the arduino board that communicates to smartthings the same way a zigbee switch does. Smartthings would have no idea it isn’t a switch, and thus it could run locally. (Is there a good example of this? Or is there some reason this can’t be done (that I haven’t found the right keywords for).)

Further, I was wondering, could I replace all 5 of the zigbee plugs/relays with one zigbee receiver that responds as 5 separate zigbee devices. Again, smartthings would have no idea it isn’t 5 separate switches, and everything would locally. (Is there a good example of this?)

I wouldn’t make any custom smart app for this, as that would make it back to cloud execution for the hub. As an example, when a motion detector is tripped, switches 1-4 turn on and switch 5 turns off, that would in turn set the lights to a certain mode.

Am I making any sense?

So do the cree dimming levels run locally? They didn’t for my sylvania light strip.

1 Like

I am about 99% sure you can choose to use a Device Handler that runs locally for a Cree bulb. I am running most things on Hubitat these days, so I have 100% local processing for all of my devices and automations. This includes using ST_Anything on an Arduino or ESP8266 board.

But, back to the Cree Zigbee module… It is fairly easy to remove, and the bulbs are inexpensive, so not much lost if you destroy one. The Cree Zigbee module has two digital outputs, one for “On/Off” and the other for “Dim Level”. The Dim Level output is a PWM signal. If you only need 5-10 “values” for your lighting project, that is trivial. Just let the Arduino measure the PWM signal and then you can “bucket” each range into a set of 5 to 10 values. Once you know which “value” is being called for, you can run the corresponding lighting effect.

Getting all 100 dim levels reliably is a bit of a challenge. I used this little project as a learning opportunity to play with Arduino Interrupts. This was the only way to get the precision needed to ascertain all 100 levels from the PWM signal. There may be better solution or designs, especially with the current, more powerful micro-controllers on the market. The reason I point this out is because NeoPixels require very accurate and precise timing signals to work properly. I wouldn’t be surprised to learn that the Neopixel libraries use the same interrupts to achieve this.

Hopefully this makes sense. If not, feel free to keep asking questions. I have been hoping for years that someone would use my old project for something cool! :slight_smile:

2 Likes

Thanks for the tip.

I’ll check out the cree bulb in the ide, and see if it will allow me to do a local automation.

1 Like

If you’re going to have an MCU, which not just connect that directly to ST? There are a few options available if you wanted to use a digital LED strip with an ESP8266 board for example that would integrate with ST but allows for direct control of the board locally.

I think the big clarification we have to make is when the OP is saying “local control” are you saying local control of the device on the ST hub or local control of the device physically by a human being that is not dependant of the ST cloud?

FYI, that controller is for analog not digital LED strips. And the person was talking about LED strips, not notification lights like the Homeseer switch.

1 Like

“Local Control” always means cloud independent control in the context of SmartThings.

No - an MCU does not have “local control” in SmartThings. There is no locally execution of the required custom DH.

I mean that when you go into graph.ide.smartthings.com and select devices, the execution location will show up as Local instead of cloud. Then I can make an automation for it with the smart lighting app, and I can go into the events tab on smartthings ide, and it will show as local also. Then when a switch is flipped in the room, it will run regardless of if the internet is up.

image

For that to all work, I need to have zigbee on my device, and I need to make it look to smartthings like it is a device it already knows. I think, right? If smartthings thinks I have added another switch it should run it locally?

2 Likes

Obviously not limited to just ZigBee.

I don’t know either way … but is the Hue Bridge DH “local”? If so, it is pretty “easy” to emulate a Hue Bridge.

Yep it looks like LAN Hue bridge runs locally.

I didn’t realize lan connected devices could also be local. Thank you for pointing that out.

I think that is just what I’m after. I found this project diyhue. Thank you.

2 Likes

Yes, this is true, if the device that is also triggering the SmartLighting App is also local. So, it can’t be any device with a custom DTH. Once you have any device with Cloud required, the entire thing goes to the cloud. So, if for example, you wanted to use a contact sensor and that contact sensor had a custom DTH, the entire smartlighting app would be in the cloud and would not run locally.

If you are trying to go local for a hue strip, you don’t have to use an official one. I’m using DIYHue on Hubitat and it works perfectly. Just can’t log into the hue API so you can’t use certain native Hue integrations. But allows for your own DIY hue-like devices. I have 4 strips and 4 bulbs on it now.

Thanks. I’ll check out DIY Hue also.