Before being away for a week, I ran into a situation in which I thought I had learned that Swap Device doesn't really swap devices (as in a two-way exchange) but instead replaces the first device with the second one-way. Indeed, the terminology used on that page seems to make it clear that's the way it works. There would be no reason to refer to the two devices as "old" and "new" if it were a two-way swap. Also, the similar function in the Add Device UI calls it replace, not swap.
However today, I did a simple test to be sure before I posted, and found that in my test, it actually does do a swap.
My feedback is that the words used here make it clear whether it is a replace, or a swap. I'm still unsure which one it is, but it is either one or the other.
[P.S. Child or parent devices weren't involved in either or the scenarios I was looking at. I'm aware they aren't eligible for this function.]
It swaps the DNIs of the two devices. By swapping DNIs, one device is replaced by the other in apps (the underlying intention). Apps refer to devices with their DNIs. So, limiting this to the meaning of these words doesn't really do it justice. The goal was to have an easy way to update all of these app references, and we realized that we just had to change what the DNI meant, what actual device it refers to.
For the devices, it swaps the two DNIs; for apps it replaces one device with the swapped device. It's intrinsically difficult to discuss. It was not intended to "replace" one device with another per se, only in the context of an app's use of a device. If some app references the new device before a swap, after the swap it would reference the other device. We assumed that when you want to replace a device for every app, that the new device wasn't being ripped out of other apps by this step, although nothing prevents that outcome.
This can't work for child devices as a child device has more than just a DNI that references it, it also has a parent (app or device). Messing with a parent or child device DNI just won't give the desired result, and there is no way to recreate the parent-child relationship for some other device (only the parent can create its child).
Well I'm still on the highest version of the last major release, 2.3.9.200, but in that version I just swapped a parent (with children) with a standalone device. The children ended up under the new standalone device.
Things got messy (and broken). I quickly realized my mistake but had to make two new devices (one new parent/child and one new standalone) and manually move all the apps.
What is the driver in use by the parent device? I think the selector prevents child apps, not parents, but then it never occurred to me that someone would think to attempt to swap a parent device. I will look into the code for this selector, because it definitely should not allow a parent device.
I appreciate that. I also understand fully about child devices (and now regret bringing it up ) .
It sounds to me like swap is closer to what actually happens. Let me ask it this way, is there any difference in result between these two? If not, I'd suggest the word replace is overworked here and the "old" and "new" give the wrong impression.
OK, you're being technical, and the use case is "I want to replace a device in every app that uses it." It's a tricky task to pick wordings, and ultimately somebody decides what it should be.
It is recommended that the "new" device not be in use by any apps yet (these will not remain associated with the new device; they will be swapped to the "old" device)
I ran into this when replacing some Inovelli switches that have their LED's as child devices. Luckily, I noticied it on the first one, fixed it, and moved on with lesson learned. My workaround was to remove the child devices, do the swap, then recreate the child devices.
I would love to still be able to do that with the known caveat. If there is a way to check if the item actually HAS child devices vs whether it just has the capability, that would be appreciated. Otherwise, maybe just have a pop up with a strong caution if it happens to be a parent driver. It is still useful for some parent devices as long as you can remove/reinstall the children easily.
It was the community driver for cloud based Mitsubishi heat pumps, I had reworked it by combining parent&child code into a single driver for local only control of a single unit (new names & name space). After a week of using both, I decided to switch all my apps, dashboards and rules to my new driver. It was my fault but I thought maybe a swap would get me half way there. Nope. A real tangle, just tedious to undo.
Actually, there is no way to tell if a selected device is a parent device with child devices. It is possible to tell if one is a child device. So, this has to be documented, and some understanding of what's going on is needed.
An idea was brought up in another topic: would it be possible to have an app that would work in a similar fasion to the Export-import-clone app, that would allow changing all the "source" references in apps from one device to another ? Swapping from the other end of the dependency, so to speak.
Gotcha, I just got the impression from your comments that you were looking at blocking parent devices from being selected. I just wanted to make a request that the block not be unilateral as it can be used with caution in some cases on parent devices and would hate to lose that capability.
Further to the swap function, is it correct that when doing a device-swap the assigned room does NOT get swapped?
I swapped two similar devices today and it appears to have gone ok but i had to manually swap the allocated rooms.
thanks
further to the last post, it appears to have broken one of my basic rules.
it was a simple rule to set the TRV setpoint to a value at a set time once each day. nothing fancy.
Can i recover this rule or do i need to delete and recreate?
I'm now concerned similar may have happened to other rules.
error
java.lang.IllegalArgumentException:
The JSON input text should neither be null nor empty. on line 1204 (method mainPage)
i think it is trying to address the device by a name that has been changed, see below.
The device, since being swapped, is no longer called "Radiator"
and when i try and create a new app with the same rules i get:
Unexpected Error
#### An unexpected error has occurred trying to load the app. Check [Logs](http://192.168.1.3/logs) for more information.
Error: The JSON input text should neither be null nor empty.
as soon as i hit update i get the " Unexpected Error" message and can get no further
If i check one of the other available TRVs and not the TRV_LivRoom the rule appears to work. Could it be the driver and attempting to address a parameter that does not exist?
) .
