So the biggest reason we have a new DTH (Virtual Switch) instead of using the existing one (Simulated Switch) is because we wanted to make some changes to the functionality (primarily 2 things, removing “physical” event type, and marking all events as a state change), and doing so could break some users existing integrations. So we decided to create a new DTH so that we can worry about the deprecation path separately from providing the new behavior we wanted (local execution).
Does this mean the switch will still pass an on command even if the switch is already on?
Is there an easy way to tell all automation that is using a Mode? Prior to getting heavy into Webcore I had a Mode called Visitor that I used to disable a lot of automation. With WC I setup a simulated switch called Visitor Overrides and used that instead. Now that we are going to have local virtual switches, I want to swap all my SmartLighting to use that instead of the Mode. So any easy way to make sure I get them all before removing that mode?
For this change, there was a good amount of work behind the scenes to rework various internal bits of how the LAN code works to address some long standing issues with that code. Examples of things we know this change should address include occasional deadlocks (resulting in hub reboot) as well as allowing a much larger number of concurrent connections (this usually doesn’t come into play often unless talking to a device which doesn’t close the connection, leaving requests to time out). The difference will likely not be perceptible, but there should be reduced latency for LAN requests on the hub with these changes as well.
I would say there is definitely a chance that this change will resolve the issue and it would be good to retest this case. Depending on what the SA is trying to do there is some chance that it may being rate throttled by another part of the infrastructure.
I am not aware of this specific issue but don’t believe any of these changes would help with SmartCam detection at all.
Any chance the connection issues with Samsung TVs will be fixed soon? I won’t hold my breath.
Good or bad there should be hopefully some info available soon, the Hub fw is not the issue
If the hub firmware isn’t the issue, how come I could control my tv when I installed it, but after a firmware update, there’s no longer that possibility?
Or is this one part of Samsung not talking to another part?
It was firmware pushed to the Samsung TV that broke the smartthings integration. Not firmware pushed to the hub. Our TVs not working is the fault of Samsung’s TV side not the smartthings folks. Which is why it’s not fixed yet. The TV guys don’t care.
Yes, that is exactly what it means.
Not that I’m aware of, unfortunately.
It’s on our list. I’m guessing I (or someone else) said something similar last time, but we do want to move as much stuff locally as possible. We’re working on it, but I can’t promise when it will be done.
It would be great to get the Fibaro dimmer 2 to run locally. And also the zw5 version of the fibaro sensors.
It would make all my Smart Lighting automations run locally.
Looking forward to Thursday so I can post about whether my hub has updated or not.
ooh, seconded. These are really useful to us poor UK users with a) no nice smart light switches and b) often no neutrals for fancy switches anyway. Also its competitor, the Aeotec nano dimmer.
…not that we want to turn this thread into a wishlist
Just a simple question, is this hub fw release tied in with any other Samsung device fw update ?? i just noticed another Samsung device has had a major FW bump
Nope, unless there is something like a critical security fix required across multiple products, teams/devisions within a company as large as Samsung are generally operating completely independently.
Buga… the Tv`s just got a big bump and i sooo wanted the damn thing to work with St again… oh well back to wishing again, thanks for the reply Paul
Well, one hub successfully updated … one more to go …
Second one updated successfully
It appears after the FW update that a virtual device created the old way in the IDE using Simulated Switch remains cloud-based according to my IDE even when the hub field is specified. Did I misunderstand what was being said in the posts I quoted?
EDIT: After reading again I see what is being said is it’s only the NEW virtual devices types that are now local. I’m leaving my post here in case anyone else had the same confusion as me.
yes, you need to change the Type to the new one
Thanks. Updated my post above. I just read the earlier posts incorrectly.