But then I got 2 messages
Hopefully cracked the OAuth2 login refresh, so the 24 hour limit should be gone.
Hello Adrian, Would you have any idea why Ring Alarm Contact Sensors are not being found by the ST Community app? They are Z-Wave devices that are using a SmartThings Custom Edge Driver that was created by Developer Milan Jurovic. Here are the device’s metrics and raw description:
The app interfaces to a SmartThings account, so if you have added them to SmartThings then I guess they should be available to the app.
To be honest, with the pending change to SmartThings API policy, I might have to pull the app in a few months, so if it doesn’t support them now, I won’t be spending any time developing the app further until I know the repercussions of the change.
I completely understand your hesitation regarding SmartThings’ pending API policy changes, but I really appreciate all the work you’ve put into this app. It does a fantastic job interfacing with SmartThings!
Nearly all of my devices are discovered flawlessly, including Z-Wave, Matter, and Zigbee devices. When I updated to the OAuth connection yesterday, additional Z-Wave switches and Z-Wave contact sensors were picked up, but the Ring Alarm Z-Wave contact sensors specifically were not.
(In the images below, those framed in red are GE Z-Wave switches, the blue frame is a Ring Alarm Z-Wave Motion Sensor. My Ring 2nd Gen Keypad was discovered as well.)
Since the Ring Motion Sensor and Keypad transferred fine, I’m wondering if SmartThings exposes the Ring Contact Sensors under a different capability profile or security category in their API endpoint?
One detail worth noting is that these Ring Contact Sensors were paired to SmartThings using Z-Wave S2 security. Since the Ring Motion Sensor and Keypad transferred fine, I’m wondering if SmartThings exposes S2-paired Ring Contact Sensors under a different device profile or custom capability schema in their cloud API?
If there’s an app log or device JSON payload I can grab from the app settings to help you see how SmartThings presents those contact sensors, please let me know. Thanks again for your support!
Update on the Ring Sensors: "I wanted to share one more detail that narrows this down: both my Ring Motion Sensor and Ring Contact Sensors are using Milan Jurovic’s custom Edge Driver (‘Z-Wave Ring Sensor’ from Milan’s channel).
The Ring Motion Sensor transfers into Homey perfectly, but the Ring Contact Sensor does not. Since both use the same driver channel, it looks like SmartThings is presenting the Contact Sensor’s profile or primary capability category slightly differently under this driver’s fingerprint than the Motion Sensor."
UPDATE: Not sure what you did Adrian, but the Ring Alarm Content Sensors are now displaying inside Homey Pro. Thank you for your kind assistance. ~ Bud ![]()
Samsung EHS Cascade Controller MCM-D3E0N – improved EHS / cascade support
Hi @Adrian_Rockall,
First of all, thank you for all the work you have put into the SmartThings Community app. It is very useful, and thanks to your app I have now managed to get my Samsung EHS system into Homey.
I have a Samsung EHS Cascade Controller MCM-D3E0N controlling three Samsung heat pumps. The cascade controller itself supports up to eight heat pumps.
The system is connected to SmartThings, and I can add it to Homey using the SmartThings Device driver in your app.
My installation consists of:
- DHW
- Zone 1
- Zone 2
- Three active heat pumps in the cascade
SmartThings currently exposes the following components:
mainINDOOR1INDOOR2heatpump-1throughheatpump-8
I have verified the mapping as:
main= DHWINDOOR1= Zone 1INDOOR2= Zone 2
In Homey this results in three devices:
-
Heatpump: main -
Heatpump: INDOOR1 -
Heatpump: INDOOR2
The zone temperatures and setpoints seem to work quite well.
There is however one clear issue with main / DHW.
SmartThings reports the DHW temperature correctly and also reports the correct target temperature. The DHW target is currently 65 °C, and SmartThings reports the allowed setpoint range for main as 40–65 °C.
Homey displays the current DHW temperature correctly, but the target temperature is shown as 35 °C.
I have attached a screenshot showing this. In the screenshot the actual DHW temperature is approximately 68 °C, while Homey shows the target as 35 °C.
It looks as if the generic SmartThings Device driver is using a normal Homey thermostat temperature range instead of the EHS DHW range.
The other interesting part is the cascade itself.
SmartThings exposes heatpump-1 through heatpump-8 using:
samsungce.ehsCascadeOverview
In my installation, heat pumps 1–3 are active, while heat pumps 4–8 contain null values, as only three outdoor units are installed.
For the active heat pumps SmartThings exposes information such as:
- Heat pump ID
- Operation time
- Energy usage
- Operating mode/status (
heating,dhw,stopped, etc.) - Error code
- Backup heater status
- Backup boiler status
- Demand response status
- PV status
- Outdoor temperature
- Water inlet temperature
- Water outlet temperature
It would be great if the Samsung EHS driver could recognise this cascade structure and expose more of the EHS-specific information in Homey.
Ideally:
mainrecognised as DHW with the correct setpoint rangeINDOOR1andINDOOR2recognised as the two heating zones- Active
heatpump-xcomponents detected automatically - Individual heat pump status, operation time and energy data available in Homey
- Unused heat pump slots ignored when their ID/data is null
I have also exported the SmartThings Advanced Attributes and Commands data and uploaded sanitised versions here:
The private IDs, serial number and location information have been removed.
I also have the complete SmartThings Raw JSON available if that would be useful, and I have access to the physical cascade controller if you would like me to test anything or change parameters.
Thanks again for your work on the app, and for considering support for the Samsung EHS cascade controller.
I’ve got a Meross MTS960 Smart Wi-Fi thermostat that I’ve added but the power consumption from the device is not exposed through Smartthings. Any possibility to add this?
ATM I am waiting to see the outcome of Samsung’s latest news that they want to start charging for API access. If they are going to make the developer pay then I will have to pull the app, but if they charge the user then I can possibly continue although I won’t be paying, so it will be difficult to test anything. After they pulled the lifetime access code and time limited them to 24 hours, I replaced the few devices I had on that platform, so all I have now is my washing machine and it’s no big deal if that stops working with Homey.
So, I currently have a few logs queued up for extra support and you are welcome to send your log if you want to.
Thanks Adrian. I’ve now sent the Detected log.
I really appreciate the work you’ve already put into the app, and I completely understand the uncertainty around Samsung’s upcoming API pricing changes.
If you decide to look into the EHS Cascade support, I’d be happy to contribute €100 towards the work.
Just let me know the best way to contribute.
Hello Adrian. I will soon be installing a new machine from Samsung. Samsung Bespoke WD11DB7B85GBU3 combi washer/dryer, is this supported in your program?
I can’t say for sure, but the app picks up properties rather than specific devices, so there’s a strong possibility.
ok that’s great then i guess i’ll put it in as a washing machine. thanks for the reply ![]()
Hi Adrian,
I’m using the SmartThings Community app with a separate Samsung refrigerator and Samsung freezer. The integration works well for the door contact status, but I have found a potentially serious issue with temperature control.
SmartThings shows the correct temperature ranges for my appliances:
- Refrigerator: 1°C to 7°C
- Freezer: -23°C to -15°C
In Homey, the devices are created as:
Kylskåp: mainKylskåp: onedoorFreezer: mainFreezer: onedoor
The onedoor devices expose both measure_temperature and target_temperature.
For the refrigerator, Homey correctly reports the actual temperature, but the Set the temperature Flow card exposes a range of 5°C to 40°C.
For the freezer it looks even more incorrect. For example, Homey currently reports:
measure_temperature: -19°Ctarget_temperature: 4°C
while the Set the temperature Flow card again allows 5°C to 40°C.
This obviously does not correspond to the freezer’s actual SmartThings range of -23°C to -15°C.
I also tested the refrigerator. It was set to 4°C and I changed target_temperature to 5°C from Homey. SmartThings immediately changed the refrigerator setpoint to 5°C, so Homey is actually able to send temperature changes to the appliance. The control lock on the physical refrigerator display does not prevent remote temperature changes through Homey/SmartThings.
Because of this, I am concerned that an accidental action, Flow configuration error, or software bug could change the refrigerator/freezer temperature to an unintended value.
Would it be possible to:
- Map the correct temperature/setpoint capabilities and ranges for Samsung refrigerators and freezers, and/or
- Add an option such as “Allow temperature control”, so that temperature control can be disabled?
Ideally, when temperature control is disabled, I would still like Homey to have read-only access to:
- Door open/closed status
- Current refrigerator/freezer temperature
but without exposing a writable target_temperature or Set the temperature Flow action.
For my use case I only need the door status so Homey can announce a warning through Google Nest if the refrigerator or freezer door has been left open.
The new SmartThings Community integration is correctly updating alarm_contact for both appliances, so that part is working very well.
Thanks!
Hello @Adrian_Rockall ,
I recently started using your app.
I’ve added my air conditioning unit (Samsung Geo 35), and was very happy to see that your app is showing the estimated energy consumption value as Power delta.
However, the app doesn’t seem to store the total kWh usage correctly, so I can’t display the device and its (estimated) consumption in Homey Energy.
Diagnostic ID: b7bd0b84-283e-4ab9-9ee6-16e061d1c175
Best regards,
Alfred
The refrigeration driver removes
alarm_contact.cvroom. On my
RF65DG9H0ESR Samsung reports cvroom
(flex door) correctly, checked in
SmartThings. Add a little smartness to your things..
Could it be added?
Hi adrian, I’m having trouble pairing my five Tapo DL110 locks using version 2.0.40 of the SmartThings Community app on Homey Pro. All five locks appear in the Detected tab, but pairing fails with an “[object Object]” error. diagnostict report 2d516c6a
Could you help me troubleshoot this? Please let me know what logs or details you need. Thanks!
@Adrian_Rockall this just came in the mail, what does this mean for your app ?
You’re receiving this email because you have a Personal Access Token (PAT) registered on your SmartThings account. We’re writing to let you know about upcoming changes that affect PATs.
What’s Changing
As part of our ongoing efforts to scale and maintain the SmartThings API, we are updating our legacy PAT policy.
- Expiration Date: Your PAT(s) will expire on December 15, 2026.
- Impact: Any scripts, personal dashboards, or third-party connections relying on this PAT will stop working after December 15, 2026, unless migrated to a paid supported API plan.
New Developer & Business Plans
PATs are intended for short-term development access to the SmartThings API. To support ongoing continued access to the SmartThings API, we recommend using OAuth through our SmartThings API Developer or Business plans.
On November 4, 2026, we released updated API plans for both business partners and individual developers.
Next Steps
To learn about how to continue operation of your integrations:
For Individual Developers: Visit the SmartThings Developer Center starting November 4, 2026 to sign up for the Developer Plan to maintain your current integrations and/or to build a new API Access App.
Availability for the individual Developer Plan: Note that the SmartThings API Developer Plan will be limited to certain countries upon launch. Country availability can be found in the FAQs on our SmartThings API page and in the Developer Center Console.
The December 15th date applies to all affected PATs including those owned by developers in countries where the Developer Plan is not available. If you have questions about your situation, contact developer support.
For Business Partners: To discuss pricing tailored to your usage, please contact us at partners@smartthings.com.
Plan details, pricing, and availability are subject to change.
For full details, please read our announcement on the SmartThings Blog. We will continue to share additional updates regarding token management policies as they become available.
Thank you for building with SmartThings.
Best regards,
The Samsung SmartThings Team
I think it means the app will stop working ![]()
I am very confused by their documentation, so I honestly don’t know. It seems each user will need to pay, but I don’t know how you do that.
When I look in my account, I can see my logins registered as apps and it says new apps require a subscription, which appears to be £4.99 per month, but I have no idea what that relates to.






