What is the difference between system:default and system:follow?

goody · October 5, 2018, 7:18pm

I’m running openHAB 2.4.0~20181004001205-1 (Build #1380) snapshot on an rpi3. When linking and item to a channel using PaperUI there’s an option I’ve not seen before.

Please select profile:
-Default (system:default)
-Follow (system:follow)

Can some explain what these do and point me to any documentation.

Thanks, Glenn

paicl01 · October 23, 2018, 2:28pm

I have a similar problem.
suddenly, when trying to link an item to a thing, there ist a request for a profile, but I do not even get a choice, so I can not link any new item at all.
Before, I could do this without this question, and all my existing items are still working correctly.

What ist wrong with my system?
thanks
Wilfried

lostcontrol · November 29, 2018, 9:44pm

I would also be interested in that. I have Z-Wave remote controller and they are supposed to send their battery level on each actuation. My battery items are not refreshed. So today I tried to delete the link and recreate it and couldn’t find the item in the list. I tried to change the profile to system:follow and tada… my items showed up???

I don’t know yet if that will fix my problem with the battery level (couldn’t test it yet) but I’m also very interested to know about those “link profile”.

lostcontrol · December 1, 2018, 10:03am

Nobody???

Dim · December 1, 2018, 10:10am

highly doubt it

Link Profiles info:

github.com/eclipse-archived/smarthome

Introduction of Profiles

eclipse-archived:master ← sjsf:profiles_static

opened 02:11PM - 22 Aug 17 UTC

sjsf

+1322 -228

This PR now reworks the factored CommunicationManager (#4067) and makes its beha…vior modifiable by "profiles". Such profiles are basically exchangeable parts which the communication manager delegates its actual duties to. I also outlined their purpose in the profiles.md file below to become part of the documentation. The idea is to make the used profile configurable on ItemChannelLinks. In this first step the profile selection is more or less static though. Although I already anticipated a "ProfileFactory" interface (mainly for testing purposes here), this PR is still missing the configurability by purpose. As this will involve touching many files and the Thing-DSL, I would like to handle this in a separate follow-up PR. Using profiles also opens up another interesting use-case: I noticed that so far no binding implements the `ThingHandler.handleUpdate(...)` method. Technically spoken some very few do, but they don't do anything there. The main idea of this method apparently was to allow devices to run as "slaves" of other devices, i.e. react on item updates only. A typical use-case for this would be a light switch with an indicator light which should follow the state of the the physical lamp without the risk of running out-of-sync. Therefore I already added a "slave" profile which does exactly that: it listens to item updates, transforms them to commands (if possible) and forwards them to the `ThingHandler.handleCommand(...)` directly. At the same time it cuts off all other communication coming out of the thing handle. With this it would be easily possible to run _any_ device now as a slave without the need to fix/implement this in all of the existing bindings. At the same time I deprecated the `ThingHandler.handleUpdate(...)` method to prevent any new binding to implement it. I think it is fair to allow for a grace period before we drop this method from the interface. The profiles here (especially the TriggerProfiles) are required for the second part of #1043 a.k.a. #2226. I only created a RawButtonTriggerProfile here as an example and proof-of-concept. But there are more required, of course. Especially for the system channels they make much sense! Nevertheless, I would like to keep the work of implementing these out this PR as well.

not much documentation exists (until now)

xslt example: smarthome/extensions/transform/org.eclipse.smarthome.transform.xslt/README.md at cf01b8669aabaee764983b1d79fe4abf42ec7f95 · eclipse-archived/smarthome · GitHub

lostcontrol · December 1, 2018, 10:45am

Super thank you very much. Still don’t really get why I need to choose system:follow for battery-level channels to have a specific item show up in the list!!??

Dim · December 1, 2018, 10:48am

you shouldn’t
the items should show up on system:default
follow does something else and you shouldn’t use it (unless you want that advanced functionality: the channel will forward the state from the followed item to the linked item via a Channel command method)

lostcontrol · December 1, 2018, 10:59am

Weird… With system:default I have most items showing up but not all and especially not the one I need. If I switch to system:follow then I see the one I need. It seems I can switch back to system:default afterwards by editing the link. This is what I did for now.