If that is their concern, they could at least allow Pause/Stop functionality. I was upset for days after installing the washer/dryer, and I realised that the Smartthings functionality is worth close to nothing. At least, this driver allows us to set up notifications for when the device has finished its cycle.
Same... all I want to do is start my oven preheating while I am on my way home with dinner that must be baked in the oven! Was disappointed when I found out I cannot do this without someone physically there to push a button or otherwise press the stupid button after every time you use it so its ready to go for next time.
1 Like
I dont understand how to get this up and running.
Installed the fridge drivers
create a virtual device using "Samsung Refrig"
Now what? IIn the devcie preferences, its asking for Smartthings API key and ST Device ID. Where do I get that? I found at the ST IDE what might be the API key for the fridge or at least it looks like it but nowhere can I see device ID. Help
Have a look at the GitHub repository (link in the first post) and look for the install instructions
You have to keep the log open when creating the virtual device. First enter your Samsung API key and Save. Once saved, a field for "Device ID" will appear. Look in the log for the list of device ID's. Copy the particular device's ID and past that in the "device ID" field.
Yup, I saw those fields. My problem was what to enter into them. I found instructions in another post here on how to get the API. I "guessed" at the device ID and picked that string of alpha-numeric characters in the URL of the device. I guessed right. 
I must be missing something here. Got all the drivers installed, created the parent device which created the children, all good so far. After initializing, the Contact and Temperature info appears correctly for each child device but that is it. Nothing gets updated after this. I can open doors, let the temperature rise and no event is logged for any of these devices. Funny thing is if I enable Debug Logging I can see each triggered event in the debug log.
2022-11-05 07:01:41.575 AMdebugSamsung Refrigerator Parent: Attributes: [temperature:null, defrost:off, filterStatus:null, **contact:closed,** coolingSetpoint:null, rapidCooling:off, rapidFreezing:off]
2022-11-05 07:01:31.539 AMdebugSamsung Refrigerator Parent: Attributes: [temperature:null, defrost:off, filterStatus:null, **contact:open**, coolingSetpoint:null, rapidCooling:off, rapidFreezing:off]
Questions:
Model and Year?
Are you connected to WIFI using a Samsung Adapter or with built-in wifi?
Also, i need a data image of your Device's data and schedule sections (near the bottom of the device edit page) for the parent.
I think everything is working as designed and guess my "issue" is related to polling. If I set the polling to 10s then open one of the doors, eventually, within the 10s range, I will get a door open event.
I was comparing this implementation to that of ST Integration within Home Assistant. In the latter the open/close events are triggered immediately upon opening/closing any of the doors. I assumed the Hubitat implementation worked the same.
I am fortunate enough to still have EventGhost app running on my ST account and am experimenting with it. Any ST contact/temperature events are sent to EG webserver which in turns updates virtual Hubitat devices. This works for now until ST decides we can no longer run custom smartapps on their system.
1 Like
I saw on your github issue that you had problems getting the Sabbath Mode for the Refrigerator to work. I have a Samsung fridge. Is there anything I can do to help test/debug the problem?
Have you looked at getting your drivers integrated with HubiThings Replica. This looks like a good item to add to that integration and it appears they have figure out the magic to also receive events via the SmartThings API.
Throw everything away and start over. No. Of course, anyone is welcome to do this themselves and use my code as a template for their drivers. It is not a simple integration (read the notes).
I am not saying it is as simple as that, but it shouldn't be throw everything away you have done either. You have a framework for the drivers you have already created. That should all be useable. The only difference would be using HubiThings Replica method to talk to SmarThings. By using that method you also gain the advantage of not needing to use polling. It was just a thought.
From what I see, that is not how that integration works. Looking at the drivers, the system is event driven. To turn a device on, the user selects on and an event is fired. Then the app completes the process.
That being said, I am looking at the code for any ideas on communications. But I have some rules
- Must not require the user messing with SmartThings (rules, add an app, etc.) other than getting the apiKey and copying (within Hubitat) the device ID.
- Must have low resource utilization (in the past, some of these always on interfaces have caused issues).
Other issues and don't knows. How will this handle devices with multiple components (each component can be a separate device to Hubitat - i.e., the Refrig where there is a separate app for each door sensor - so that events can be tracked). Also, how are custom capabilities handled.
Dave
So in the time I have been messing with HubiThings Replica a few things have come clear.
-
The setup requires the PAT similar to your integration, and then if you setup the OATH connectivity it does require you to authenticate to the Smartthings environment. This is just like adding any other integration to Smartthigs like Arlo, or Ecobeee. It takes you to a log in page and you log in. So no app setup like Samsung Automation Studio or setting up a webhook application.
-
It is clearly Event based, as if you have that polling is not needed. I believe the PAT is used for passing commands back to Smartthings. It does keep track of what devices are matched to what on both sides. Along with that it also tracks the abilities of each device.
-
It has a Hubithings rules section that allows for you to setup a kind of replication action between Hubitat and Smartthigs attributes and commands. I believe in the drivers this can be pre-configured in a way, but can be customized after setup as well.
-
The drivers use HubiThings Replica are mostly virtual drivers designed to hold states/attributes based on what HubiThings gets from Smartthings. It appears the idea is that anything that can be pulled from Smartthings can potentially be added to Hubitat. You can also setup rules against the virtual drivers to send up dates to Smartthings when a change is made in Hubitat.
-
I don't see any multi component devices currently in the integration, so that may be a problem.
Tracking the status of a wifi device is not an instantaneous nor automatic thing in the interfaces. Using the ST Cloud API, sending a command to a Samsung device does NOT update most Samsung Appiance status (I have tested this several times). To get the status, you must first REFRESH the device and then POLL the device through the interface.
With the OAUTH, you only have to refresh (from Hubitat or SmartThings) - but you still have to refresh before the subscription is sent from the ST device. Concern is how this works. The documentation for HubiThings Replica states that the subscription database can only be accessed 15 times in 15 minutes (no more than once per minute average). That may be an issue.
Honestly this doesn't make sense and I know I have never sent refreshes when I have used a smartapp with a webhook on the Smartthings API. Once i have subscribed to a device wifi or not they just are sent to my endpoint when the event occurs.
Well I am not trying to convince you to do anything if you don't want to, I just thought of you and your drivers as i was researching it.
I know (and verified yesterday on my Samsung TV) that the device's attributes are not updated unless a refresh is sent (and executed) by the device. I sent a volume command and viewed the device status. It over 25 minutes - it never changed. Sent a refresh command and it updated immediately. So make sense or not, it is what the interface shows. I repeated the test several times on other commands (waiting two minutes).
Of course, this is Samsung devices with the Samsung developed driver. I can not say the same thing for other devices/drivers on the interface.
Brings to mind a question. What of my drivers would you like converted to REPLICA. I, of course, have some serious questions on the OAUTH app and how it works and how often given the rate limit.
I did look at the Samsung Air Conditioner. Has all apparent hooks (and a lot more that I implemented (on purpose).
I wish I had a similar device to test this with. My Smartthings API stuff is limited to using Arlo cameras with smartthings being a Cloud aggregator. I can assure you in that case motion events are sent immediately. I actually use Node-Red with a Samsung Automation Studio pallet to setup the smartapp and create a Webhook endpoint for the events to be sent to. My rason for bringing this up isn't about a particular ask for myself, but just to make sure you are aware. I saw this smartapp and though this could work really well with what you have already accomplished.
Smartthigs API Rate limits are listed at: Smarthings Developer Documentation (Rate Limits and Guardrails)
If that URL is to believed you can have up to 20 devices subscriptions on a single app and then you can only create 40 subscriptions in a 15 min interval. These rate and guardrails are about what you can setup though. I don't see anything saying Smartthings will limit how many event notifications it will send out in that list. It does mean you could be limited by sending commands back to Smartthings, but not receiving events. I would imagine that list of Rate limits also has a impact on your drivers as they are all outbound calls.
2 Likes
