I’ve just started my journey in home automation and Smartthings. My setup includes Aeotec smart hub, some Aeotec sensors, outlets etc. However some of my lights work with Eltako switces and dimmers(for example PTM215 DB). I did start the developer environment in ST. In coding i have experience in c++ and python but not in Groovy.
Eltako uses EnOcean as the protocol and based on my quick research, i did not find a solution to integrate these to my Zigbee/Z-Wave network and especially to Smartthings. (on/off is enough for the lights). In my region EnOcean uses 868Mhz.
One product i did find was the EnOcean USB 300 that could possible read and see the signals, and thought that maybe it and Raspberry pi could be a solution? Does anyone here have experience in EnOcean and if this is even possible, also if the app is even possible to create to this problem? And if so, is this even worth the effort?
Enocean has devices that operate on several different frequencies. Most don’t match the radios that a SmartThings hub has.
The only ones that do are part of the Zigbee Green Energy profile, but while the radios match, the SmartThings’ implementation of Zigbee does not support that command set, so those don’t work with ST either.
So…,yes, the only way to do it is to build your own bridge device. I haven’t heard of anyone who’s done that specifically, but I would think the easiest way would be to look for enocean to MQTT projects, then use MQTT to bring it into SmartThings. That has the very real advantage of being something that could be made to work with the new ST architecture.
As for whether it’s worth the effort, only you can say. The cost shouldn’t be too bad, there should be some existing sample projects for each half of the bridge (enocean to RPI, MQTT to ST), and again the MQTT part should survive the ST transition; if you design it to do so.
I’m going to tag @mwav3 in case he has any additional comments on the MQTT to ST piece.
edited to update
Looks like there are some out of the box enocean to MQTT options. But I don’t know if it’s two way, which you would need for light switch control.
That said, its incredibly uncommon. You’re either building the entire solution from scratch (your on the right track, then you’d have to write an “edge driver” to manage the interconnect. Consider Groovy End of life Edge (LUA) is the way forward.
@TAustin was doing something like this for some specific high traffic devices gor instance, a websockets endpoint) but TBH I have NO clue who else would use this. So while it might be a fun research project, (if i did it it would be purely academic) its tickling my SpideySense on the ‘worthiit-o-meter’ at 25USD each ill just not get Starbucks this week and replace the switch with a ZWave or ZWave one.
If that MQTT thing works ot would be the easy way, but who knows. You are on a very untrodden path
And here’s an old example for Home Assistant using a raspberry pi with an added enocean radio. Same idea. Bring the enocean signals in, use mosquitto as the MQTT broker , communicate via MQTT to home assistant. So there is an added hardware piece plus software on both ends of the bridge
The new ST architecture can be accessed via MQTT, so that’s the direction I would start, but I don’t know much about the details.
I didn’t specifically say there was a “MQTT interface,“ but you can use MQTT with some of the new API options.
It’s officially possible through the new architecture for “direct connected“ devices, which are Wi-Fi devices that are not using their own cloud. (These are distinguished from “hub connected devices,“ which are the ones that use edge drivers and are intended for Zigbee and Zwave.)
That said, people have been unofficially using MQTT with smartthings since at least 2015, mostly with custom smartapps to mosquitto. You won’t be able to use the custom groovy smartapps for much longer in the free smart things cloud, but you can host whatever you want on your own server.
Some people use Node-Red to get to MQTT.
And the very new Samsung Automation Studio allows you to bring node-red into smartthings.
Again, though, I don’t know any of the details on any of these. I just know that there have been conversations about them. That’s why I tagged @mwav3 .
Ah ok, if you are thinking of Direct Connected devices, MQTT is mentioned in the marketing for purely…um… marketing purposes. There is no access or use of MQTT by direct connected device drivers (I have developed a few myself). They use the SDK API which really has no relationship to MQTT. Here is the API direct connected devices use for reference: st-device-sdk-c/APIs.md at master · SmartThingsCommunity/st-device-sdk-c · GitHub
… really nothing to do with MQTT protocols. That is completely under the covers. So there’s no benefit in looking for code that uses MQTT if you want to integrate with SmartThings. It will have to use the SmartThings SDK API or one of the other schemas.
Ok, fair enough, as I’ve said I know nothing about the details.
I do know people have been successfully using MQTT with the old architecture for years, as in the following:
And I’ve been told by several different people that their intention is to use MQTT to webhooks to get directly into the new architecture. But I haven’t seen a specific example of that yet.
People I know who have actually done something have been using MQTT to node-red to Samsung automation studio. But again, I am clueless on the details.
I know you’ve done a great deal with this, so definitely anyone should take anything you say as more accurate than any of the broad strokes stuff I’ve put here.
Unless its changed recently there was a HUGE problem with it. You could only subscribe to one device (smelled like a proof of concept / beta limitation) but it was enough to make it useless for my purposes abd I abandoned it within a few days.
Okay, i see. Based on these comments this could be a fun hobby project but for now i would almost go with just replacing the existing relays/switces with new ones. I really like the idea of creating my own bridge EnOcean->MQTT and from there to ST and using RaspPi. On my skill level this is waay to much effort because MQTT is unknown for me as well as the ST custom apps. If you have any suggestions of relays that can utilize the existing wall switch, it could be helpful. And also if i were to start creating my own bridge, where should i start? Should i first try to get signal from the Eltako to Rasp by using something like Tcm300 and go from there?
To answer those, we need to know where you are (device availability varies greatly by country) and what kind of controls you need. Just lighting? Also do you own a smartthings hub or are you running ‘hub optional’ (no hub) right now?
Im currently using Aeotec smart hub that supports z-wave plus, zigbee and wifi. And for the lights i would like a possibility to integrate a switch/relay inside the wall mount in order to not change the existing wall switches. I would also like to have possibility for local and not be dependent on the cloud. Living in Finland so they need to meet the reqional standards etc mostly same in the whole EU. It would be nice having dimming feature but that they could also work as on/off switch (if bulbs changed in the future). Couple (or all?) lights i could replace with rgb ones. The existing enocean leds have dimmers but some other regular light don’t.
I’ve also decided to try the enocean integration with ST as an experiment at least. I will try to use RaspPi and the enocean pi 868 transceiver module. I did find many examples of transforming from ecnocean to MQTT and hope it will work. I can update my progress if i do get any
Just want to clarify that. While the Aeotec hub communicates to the cloud using Ethernet or WiFi, I don’t believe the hub will support/control WiFi devices.
If you want to do smart control without changing out your physical switches, I see folks here using Quibino devices. They’re EU based so I’d expect they have something that would work in Finland. Search the forums for folks using Quibinos.
Aeotec makes similar inwall modules in all three device classes: basic on/off, dimming, and motor control such as for fans. I believe their nano line is even smaller than the Qubino. And since they are SmartThings’ hardware partner for the EU, I have higher confidence that there will be Edge drivers for them soon. (Qubino, in contrast, is not even working well for all models with the Groovy DTHs with the V3 app: see recent forum discussions.)
Also, Aeotec nanos are one of the few modules that can do dimming with a dumb switch with some setups.
So during this transition period, I would put Aeotec at the top of the candidate list for zwave dimmer modules in both the US and Europe.
There are some zigbee choices that people have already developed Edge drivers for, or the Sonoff WiFi modules are another possibility (but sadly not their zbmini zigbee line, which are a great price but are having Edge driver issues right now).
So there are quite a few choices these days, just be aware that “works with the existing dumb switch” doesn’t always mean “dims from the existing dumb switch.” It might just be on/off, with dimming only available through automations or the app.
Also, not all models will work in a two way setup. So you just have to do some research on the specific candidates.
Just a little update as well as tutorial for beginner like me on how to start with the EnOcean Pi. I ordered the module EnOcean Pi that has the TCM 310 chip on it. It attaches straight to the last pins on my Raspberry Pi 3 B. The biggest obstacle to get it workin is the TX and RX pins it uses. These are used for Bluetooth in Pi 3 B and need to be disabled. By deleting console=serial0, 115200 from /boot/cmdline.txt and adding enable_uart=1, dtoverlay=disable-bt and force_turbo=1 to /boot/config.txt the pins are move so that ttyAMA0 and ttyS0 can use them. If we would want Bluetooth we could add dtoverlay=pi3-miniuart-bt so bluetooth uses miniuart in this case (?maybe?) more of this in the Pi documentation. Before all this update etc your rasp.
I tested this with hexdump -C < dev/ttyAMA0 and it shows nothing until i press my PTM215 to send signal and some data came through. You can also use EnOceanSpy library to do this. For me this was a problem because i thought is would send even something even though no EnOcean signals are transmitted and this took me a while to understand. You can use ls -l /dev to see the pins which should show something like serial0 → ttyAMA0 and serial1 → ttyS0 or the other way around, dont remember.
After this i installed FHEM just to test and used the WEB to access it and after adding one switch the EnOcean page came to the left side. Before installing fhemn you need some libraries (check documentation). Another problem was that i could not teach a single product. I figured it out that Eltako TF100D, if it has a existing button attached, you activate the teach mode with that particular button or any other attached button. And i got it working, i could control the dimming outlet with it. Next step is propably to integrate this with ST somehow, i will see my options, maybe create a custom application with python and with EnOcean library, who knows and i’ll be back. Picture below of the Rasp and EO Pi. Thank you for this community for support!
Hi, another update. Got this working with MQTT! I used mosquitto to run the server on my Raspberry Pi 3 B and FHEM as client. Fhem has couple options to choose from. They have MQTT2_SERVER that replaces mosquitto (i believe), MQTT2_CLIENT, MQTT_GENERIC_BRIDGE, MQTT2_DEVICES etc. In my setup i have the mqtt2_client that “speaks” or connects to my mosquitto and i have mqtt_generic_bridge with that and all this running on my single Pi 3. And i only need to define subscription and publish for my Eltako EnOcean dimmer like this (In the example i publish the state as well as subscribe it):
attr "device name aka TF100D_switch" mqttPublish state:topic=fhem/pub/state
attr "device name" mqttSubscribe set state:topic=fhem/sub/state
Now i can publish (as a test) with MQTT Explorer a state “on” or “off” and the outlet will turn on or off. When i click from fhem WEB platform or of off, it changes the state as i haven’t yet put on automatic state change when receiving subscription.
But why FHEM you may ask? I tried enocean library by kipe, but i couldn’t figure it out how i can send, receive or teach the stuff and i tried a long time to understand. Fhem had it all already especially the EnOcean products including the more inofficial ones. Kipe’s library did have most of them even though the documentation of what are included said otherwise as users had uploaded them themselves. So i mean why reinvent the wheel. And also i could make a feature with publish that creates a new switch in FHEM.
At this point i have made it to EnOcean->MQTT and now i would like some help with MQTT->ST, because i don’t know how to code with Groovy. I would need to send mostly on/off but also dimming (which i need to check how) commands.
