It’s the first time I see the profiles in use. I use these transformations on my items with metadata. Is there a reason/requirement/benefit to apply this on a channel?
see here
and profiles are more powerful. Me personally I use hysteresis profile to create events on channel level:
if temperature > 80 then a 2nd linked item of type switch is set to ON. without any rules.
@wars good question, and thanks to @Oliver2 for explanation. To be honest I thought, that for me it is not important to have the wind direction value as a number, so I made a transformation on Channel/Item level.
@Oliver2: The Hysteresis profile sounds interesting (for example for battery critical switches if only battery level is supported from the device). In the documentation the hysteresis is explained by textual configuration, but unfortunately I can’t find it in the UI?
I’m running 3.1.0.M3. Any idea, why it is not shown?
Thanks!
Can’t say if it is a bug, but if you go to thing’s channel tab and click on “+ Add Link to Item” you see the hysterese profile if the channel is a number channel.
Try to unlink and re-link the item. then hysterese should appear.
if you map hysterese profile to a switch item, make sure to add a state description to the item:
- set the item to read only
- add “%s” to pattern
otherwise you see “Err” as switch state
Could you please elaborate how you got this done?
Is this in the location tab or on the overview tab and have you created a page for it? Maybe a YAML if you don’t mind 
Thanks in advance!
Correct me if I am wrong, but that looks like the normal Location card.
You achieve this by using the semantic model assigning Equipment and Properties.
I defined my semantic model but I just don’t get the (eg.) number of light in the top part and have no “tabs”.
Ah well, if I build the overview good enough, there is no need 
Edit: Found some more options just now 
You mean the i.e. lightbulb icon etc.? Those are called badges.
The tabs, again, are defined by your defined Equipment (Group of points => Equipment tab) and Properties (single points => Properties tab), there is quite extensive documentation here in the forum that shows how to do it.
I decided to write a Jython (Python 2) rule to update a String item with the wind direction name derived from the actual wind direction Number:angle Item (in my case, returned from OpenWeatherMap):
File location: $OPENHAB_CONF/automation/jsr223/python/personal/
File name: update_wind_direction_name.py
from core.rules import rule
from core.triggers import when
from core.actions import LogAction
from core.actions import Voice
from core.actions import Audio
import pprint
pp = pprint.PrettyPrinter(indent=4)
from java.time import ZonedDateTime
from java.time.format import DateTimeFormatter
from math import floor
rule_init_timestamp = ZonedDateTime.now()
logTitle = "update_wind_direction_name.py@{ts}".format(
ts=rule_init_timestamp.format(DateTimeFormatter.ISO_INSTANT),
)
ruleTimeStamp = " -- (Rule set initialised at {ts})".format(
ts=rule_init_timestamp.format(DateTimeFormatter.ISO_INSTANT),
)
rulePrefix = "Update wind direction name | "
class defaults:
wind_direction_ANGLE_ITEM_NAME="OneCallAPIweatherandforecast_Current_Winddirection"
wind_direction_name_item_NAME="Weather_Current_Wind_Direction_Name"
wind_names_32 = [
"N", "NbE", "NNE", "NEbN", "NE", "NEbE", "ENE", "EbN",
"E", "EbS", "ESE", "SEbE", "SE", "SEbS", "SSE", "SbE",
"S", "SbW", "SSW", "SWbS", "SW", "SWbW", "WSW", "WbS",
"W", "WbN", "WNW", "NWbW", "NW", "NWbN", "NNW", "NbW",
]
@rule("Wind direction changed")
@when("Item {WIND_ANGLE_ITEM} changed".format(
WIND_ANGLE_ITEM=defaults.wind_direction_ANGLE_ITEM_NAME
))
def Rule_WindDirectionChanged(event):
# Note: rule can be triggered by hand
update_wind_direction_name()
# Update the wind direction name item (usually when the wind direction angle item changes):
def update_wind_direction_name():
global logTitle
logPrefix = "update_wind_direction_name(): "
LogAction.logInfo(logTitle, logPrefix + "At the start of rule")
wind_direction_angle_item = itemRegistry.getItem(
defaults.wind_direction_ANGLE_ITEM_NAME
)
wind_direction_name_item = itemRegistry.getItem(
defaults.wind_direction_name_item_NAME
)
if not wind_direction_angle_item:
LogAction.logError(
logTitle, logPrefix + "Cannot find wind direction (angle) item '{item}' in item registry".format(
name=defaults.wind_direction_ANGLE_ITEM_NAME
)
)
return
if not wind_direction_name_item:
LogAction.logError(
logTitle, logPrefix + "Cannot find wind direction (name) item '{item}' in item registry".format(
name=defaults.wind_direction_name_item_NAME
)
)
return
wind_direction_name_value = None
wind_direction_angle = wind_direction_angle_item.state
if isinstance(wind_direction_angle, QuantityType):
"""
Convert wind direction in degrees (0°-360°) into a named wind direction by means of an index.
Since we're producing a 32-point wind rose, 'pure' wind direction names are centred across arcs
spanning 1/32th of a full circle. Or, having equal arcs of 1/64th of a full circle at each side
as mapping intervals. In this logic:
a. North is centred at step 0
b. Scaled wind angles with values between steps -1 and +1 are mapped to north
c. Since wind directions span 2 steps, we must count the intervals at odd nonzero step values
Therefore the index can be computed as follows:
1. Convert a wind direction angle value into 2 * 32 = 64 steps
2. Round down this value to the closest integer
3. Map this value to [0..64[ using modulo (north may yield values ≥64)
4. Convert this value to a 32-step index (use Math.floor as wind name changes at threshold)
5. Look up the wind direction name by means of this index in the wind direction name array
"""
# Get the wind angle in degrees:
wind_angle = wind_direction_angle.doubleValue()
# Scale wind angle from 360° range to 64 step range:
scaled_wind_angle = wind_angle / 360.0 * 2 * 32
# North goes from -1 to +1 hence we add an offset so the index starts at 0, 2, 4...
scaled_wind_angle += 1
# Convert index to 32-step index (use floor - returns float in Python2) and reduce range to [0; 32[:
wind_name_index = int(floor(scaled_wind_angle / 2)) % 32
wind_direction_name_value = defaults.wind_names_32[wind_name_index]
LogAction.logDebug(
logTitle, logPrefix + "Mapped {angle} to index {index} and name '{name}'".format(
angle=wind_angle,
index=wind_name_index,
name=wind_direction_name_value,
)
)
events.postUpdate(
wind_direction_name_item,
wind_direction_name_value
)
You can update the wind direction item name in the rule in the defaults class at the top of the file.
I created my own set of wind direction icons, see:
To make icons dynamic in Moain UI, you must edit the Item, pick default list item widget, tick the show advanced checkbox and tick the now visible Icon depends on state option.
Have fun!
Thanks for the hint! after re-linking the item hysterese appears!
Since I try to implement a few cards based on your code I figured give you something back 
The Items list you posted for the ‘wetter’-card contains 2 times forcastDay3 in the channel config. Being both there in D3 and D4. The card that you posted above it is correct however so maybe it’s already fixed 
For the same card, to convert icons strings to the actual icon names, I use a MAP-file and then use the meta state description to produce the names. If Openweathermap ever decides to add icon ‘states’ you only have to adjust the map file. It is based on post#8 in this topic and works well.
Further I can’t say anything else then you’ve done a great job in creating widgets that are highly flexible. Using the visible option was a great idea! This way, you can use one card for multiple rooms for example without the need that every room has the same equipment (ie. temperature, humidity etc)
Are you able to share the media center YAML? Thanks!
You have a fancy weather station, do you also have a fancy soil moisture measuring device?
Hey Arjan! Yes I’m using the GARDENA irrigation system for my lawn and plants. So there is a new soil moisture sensor which can be located somewhere in the lawn. I’m using the old one.
New one (requires a Gardena Bridge): Gardena smart system Produkte smart Sensor
Thank you again Mike @Integer for your widget examples which have been a good starting point for me to create my widgets according my context by adjusting your widgets. I also found a lot of hints in the OH forum and OH documentation. Thank you to all who have contributed in the OH forum, OH documentation and OH development!
OH3 is a great product and provides a lot more flexibility and possibilities than OH2.
I’m still at the beginning to learn and understand all the new features and how to configure and implement these. It’s still a lot trial and error.
Attached find the result of my approach adjusting the widgets of @Integer according my context.
My homepage with adjusted Card_room_12 from @Integer :
One of the adjusted popup pages with adjusted cards:
The Homepage also woks on the smartphone wit the OH app:
I adjusted the widgets to work with Fibaro rollershutters which have two different items to control the blinds (Jalousien) and blind slats (Jalousielamellen) and to work with different types of lights. My preference is to select between a few options instead moving a slider (therefore I implemented 3 blind slate positions, several predefined colors for color bulbs beside the slider). Right now the the predefined colors are fix set in the widget but I plan to set these with another widget and store the configured colors in items.
I still have challenges with “relative” positioning of components (icons, buttons, …) within a widget. Therefore I have often used “position absolute” in the style definition. Another challenge are the different resolutions of my tablets. One of my 10" tablets have a resolution of 1920x1200 and another 10" tablet has the resolution of 2340x1080. The homepage works fine with the OH app on my smartphone (portrait mode) and 10" tablet with the lower resolution (landscape mode), but on the 10" tablet with the higher resolution the characters and cards are to small (the font size and row high is not adjusted according the screen size).
I also run into limitation with complexity of expressions supported for “icon-F7” in “oh-link”. It seems that “icon-F7” only supports expressions to select two different icons. I wanted to select between three icons and therefor had to override the icons twice (this might also be a limitation of my knowledge).
If you are interested I can share my adjusted widgets.
3 Likes
Thanks!
Nice thread and interesting solutions!
Here’s my current layout, mostly with custom widgets (and some AI object detection tests):
1 Like
I think, you can use more than two icons by using () in your expressions like =check ? result : (check ? result : (check ? result :alternative))
To all: can i get dynamic icons for temperature and humidity with a code like this
- component: f7-block
config:
visible: "=props.humidity_item ? true : false"
style:
position: absolute
top: 75px
left: 12px
flex-direction: row
display: flex
z-index: 2
slots:
default:
- component: oh-icon
config:
icon: humidity
item: "=props.humidity_item"
width: 18
- component: Label
config:
text: =items[props.humidity_item].state
style:
font-size: 16px
margin-left: 5px
margin-top: 0px
And how can i analyze only temperature or humidity when i click on their icons?
Hi Bernhard,
Very nice widgets. It would be great, you share the YAML code. I’m at the beginning to switch from OH2 to OH3. With some examples it makes easier to find solutions for the own smart home and sharing it too.
Many thanks!
Henry
I found some time over the weekend to describe how I organized my widgets and pages. I designed my own widgets to adjust these to my context and to allow a common design.
I use two pages, one for each floor. The page for the ground floor is the same as the overview page. Four cards “Cell_card_1A” are placed on top of the ground floor page to select several scenes (one of them “All OFF”). The rest of the page is filled with cards “Card_room_12A” to open the page for the different rooms and show the state of several items within the room. The card “Cell_Weather_1” for the weather forecast is also placed on this page.
The state of up to three lights, up to three roller shutters or blinds, one door state, room temperature and room humidity may be displayed on the room card “Card_room_12A” (can be extended). I use absolute positions for the state icons … relative positions might be the better options if you know how to do that (when using “component: oh-link“ instead of “component: f7-chip”).
A light is displayed “filled” when its state is ON. If the brightness of a light can be controlled, it is displayed with a badge with shows the brightness level.
A roller shutter is shown black filled when its closed more than 50%, not filled when its closed less than 50%. A badge is shown when it is not open (1 – 99)
A blind is shown gray filled when its closed. The lamella / slate position is display with a black arrow.
As I use one door sensor only (for the front door) and have no roller shutter in that room, I placed the state of the door at the same position as the first roller shutter (it’s easy to adjust the position if needed). The state open / closed is displayed with open or closed door.
The room temperature (set point in brackets) and room humidity is shown in the buttom line.
The pages for the rooms open as popup when clicking on one of the room cards “Card_room_12A” within the overview page or floor pages.
Within the room pages I mainly use cards with widgets for lights, roller shutters, blinds, temperature and humidity.
I use two different widgets for the roller shutters (Rollläden / Rollos). Widget “Cell_Shutter_Card_1” with the classic buttons UP, STOP, DOWN and widget “Cell_Shutter_Card_1A” with three additional buttons for three positions defined via three parameters of the widget. This is especially helpful for those who have not yet automated the positions of the shutters via sun sensors and rules (remote control vs smart). The state of the roller shutters is displayed as text “offen (open)” if its fully open or “% geschlossen (% closed)” if its partly or totally closed.
To control the blinds (Jalousien) I use the widget “Cell_Shutter_Card_2” with the classic buttons UP, STOP, DOWN and additional three buttons to control three defined positions “open / offen”, “half closed / halb zu”, “closed / zu” of the lamellas / slats (Jalousielamellen) of the blinds. Two different items are used to control the blinds. My experience is that controlling the lamellas with three buttons with predefined lamella positions is easier to control than with a slider.
I use widget “Cell_Light_Color_Card_2” for color lights with sliders for color, saturation and brightness. The widget has additional eight buttons for predefined 8 colors (currently fix set in the widget … I plan to set these with a parameter through another widget). I prefer to use several buttons for predefined colors instead of using the color slider.
Widget “Cell_Light_Card_2” can be used for white lights. One slider is for color temperature (cold – warm) and one for the brightness. Different items are used for ON/OFF, brightness and color temperature. If you use different items for ON/OFF and brightness, you can use a rule to define the brightness level when you switch on.
If item for color temperature is not defined, only toggle switch and brightness slider is displayed.
If item for brightness is not defined, only toggle switch is displayed.
I use “Cell_Toggle_Card_2” to control two different lights ON/OFF not dimmable
The YAML code for the widgets is in the next post
16 Likes