I was not successful in getting date time with 1.7.0. It always gave me a not able to connect to server error but I was busy fixing mybzwave devices so never looked further. However with 1.7.1 all seems to work well. Below is my item definition
DateTime Date “Date [%1$tA, %1$td %1$tb,%1$tY %1$tT]” { ntp=“America/Chicago:en_US” }
I am able to show date and time informations, however weekday appears in ENGLISH.
I need to show this information in another language (for example spanish, portuguese or japanese).
So… main problem is how to do this?
When I add MAP translation service and Translation rule (.map file), date and time information do not appears.
ie. run this as a Rule and look at the output in openhab.log:
import java.util.Locale
rule "Test Locale"
when Time cron "0/10 * * * * ?"
then
val Locale LOCALE = Locale::getDefault
logInfo('locale', LOCALE.toString)
end
It’s possible that some i18n elements aren’t printed correctly because the JVM settings aren’t setup (or are defaulting to US). These are typically picked up from the OS, in an OS dependent manner. For Linux, it involves specific Environment variables (think LANG, LANGUAGE)
Your openHAB machine is running on an OS that’s configured for English. Java sees that, and internally defaults it’s Locale to match.
Switch your OS over to the Locale you’re interested in, and all output/display functions in Java should cutover as well… at least they will in a correctly NLS’d (or MLS’d) app.
Internally DateTime is language neutral, so it won’t matter how values get into the DateTime, it’s more about how they format for output purposes.
How you switch the language is OS dependent, but for something common like Linux, it can be done a few ways.
The easiest is to set the LC_ALL variable prior to starting openHAB.
export LC_ALL=en_GB.UTF-8
This likely requires that you have this lang installed (OS-wise). There are command-line overrides on the JVM that’ll probably also work.
To understand how this is done for other OS’s, you can Google and/or use StackOverflow (aka SO) since the model is different across platforms, and in some cases, across versions of Java.
You’ll need to show how you’re starting openHAB, and where you’re setting the environment relative to how you’re starting it.
For example, if you make these changes in one shell, but openHAB is starting from another (like init.d scripts) it won’t be picked up. If you make the changes “system-level” in Raspbian, then it’ll probably be picked up on next boot.
I’m guessing you’ve set it in one shell, but you’re starting openHAB in another. I just tweaked my /etc/init.d/openhab script to add the LC_ALL environment to my startup sequence, per the above snippet of shell, and now my sample rule correctly emits:
12:47:53.316 INFO org.openhab.model.script.locale[:53]- en_GB
Hey guys,
I stumbled upon your thread since I had the same issues. After migrating my OH setup to new hardware my date items were in English instead of german from the old setup.
Indeed the language was set different. This is how I rectivied this on my debain server (should also work for raspbian, etc)
env | grep LANG
LANG=de_DE.UTF-8
LANGUAGE=en_US:en
export LANGUAGE=de_DE:de
apt-get install dpkg-reconfigure
dpkg-reconfigure locales
Generating locales (this might take a while)...
de_DE.UTF-8... done
en_US.UTF-8... done
reboot
While reconfiguring, choose your new language and reboot.
Hope this helps.
Here’s a tutorial on how to achieve your local language for the NTP binding.
No hassle with installing another locale on your Raspberry or other system.
Just keeping the settings of your system. It’s just a few simple steps…
Step 1 - Install the NTP Binding in OpenHab
Step 2 - Go to Things -> Local Time and link the channel “ntp:ntp:local:dateTime” to an item “Date”
(this item you can use in the future for a full date & time text. Example: Sunday, 06.01.2019 20:00)
Step 3 - Create a file called ‘weekday.map’ and put this in the folder ‘\OPENHABIANPI\openHAB-conf\transform’
In this file put the English weekdays and your own language for translation. Example:
2019-02-27 17:29:47.323 [WARN ] [rest.core.item.EnrichedItemDTOMapper] - Failed transforming the state ‘2019-02-27T17:29:47.288+0100’ on item ‘Today’ with pattern ‘MAP(weekday.map):%1$tA’: Cannot format state ‘2019-02-27T17:29:47.288+0100’ to format ‘%1$tA’
Hi Elwin @Whininie
I am using the same method for a local date time; get the same error and could not find a solution.
Did you find a solution for this?
Regards, Bert
A solution for this could be a little rule like this:
rule "test_change_day_of_the_week"
when
Item Current_DateTime changed
then
var vDay = transform("MAP","de.map",now.toString("EEEE")) // for test
logInfo("Day","Day is: {}",vDay) // for test
CurrentTime4.postUpdate(transform("MAP","de.map",now.toString("EEEE")))
end
Just create a second Item (i.g. CurrentTime4) in your ntp.items-File
I do see various topics regarding translation. The suggestion is always to create mapping files.
These (same!) mapping files are created again and again by the users, I guess the content is the same.
I started a topic sometime ago, b/c HABmin was using the correct translation for the astro binding - w/o a mapping file! But only HABmin did show these translations, non of the other UIs did. After some hints from Chris I’ve found the code which did the translation - it’s from the astro binding itself!
Currently there are two questions on my mind:
Why isn’t translation not used more within the bindings?
Why is only HABmin using the translation?
My coding skills are pretty small and haven’t been used for decades. Also I know this is an opensource project and nobody gets paid. I am just asking with the opportunity to optimize.
Yes, the MAP returns a string. Though it happens to look like a datetime, it is just a string of characters.
The java formatter datetime operator $tA cannot work with a string, it needs a datetime object. Hence the error.
You can really only use %s with transforms.
Do any formatting you want in your MAP file.
However, I don’t really see what you are trying to do with trying to lookup a datetime in a MAP list.
A datetime Item state is something like 2019-02-27T17:29:47.288+0100 and that isn’t going to match in a list of monday, tuesday etc.