My primary use case was “just” to control the fan in my RV to open/close, if there’s rain. But now I’m of course connecting everything in the RV to an raspi running openHAB.
one thing what’s different is of course, that an RV doesn’t have a fixed location. Is there anything I can do to change the location? Primarily for Astro binding (a few sunset/sunrise actions) - but also for weather bindings like openmeteo? How would I do that - if even possible?
Hi,
You can read, change and write back the configuration of the thing via the Rest API. Here is an example with Javascript for Astro (created with Blockly)
var sUrl, oHeaders, sResponse, oJSON, newLocation;
function toJSONString(params) {
if ((typeof params === 'string') || (params instanceof String)) return params;
return JSON.stringify(params).replace(/^"+/, '["').replace(/"+$/, '"]');
}
sUrl = 'http://192.168.178.50:8082/rest/things/astro:sun:local';
oHeaders = {
'Authorization': 'Bearer oh.TestRule.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
'WWW-Authenticate': 'Basic'
};
sResponse = (actions.HTTP.sendHttpGetRequest(sUrl, oHeaders, 3000));
oJSON = (JSON.parse(sResponse)
);
newLocation = '45.095002,-87.644520';
oJSON.configuration.geolocation = newLocation;
console.warn((actions.HTTP.sendHttpPutRequest(sUrl, 'application/json', toJSONString(oJSON), oHeaders, 3000)));
E: just try something ^^ It can also be done without reading + changing by sending the complete ‘configuration’ value directly.
console.warn((actions.HTTP.sendHttpPutRequest(sUrl, 'application/json', toJSONString({'configuration': {'geolocation': newLocation, 'useMeteorologicalSeason': false, 'interval': 300}}), oHeaders, 3000)));
of course!
So a rule could write the location at least once a day (e.g. midnight) to the Things, that are location dependend.
thanks!
AFAIK, the current binding only reads the config on initialization. So perhaps you need to stop and start the Thing after this.
You don’t need to go around via REST API from your script. The only time you need REST is when your code is running externally.
Example in Ruby:
def update_astro_location(thing_uid, new_location)
astro = things[thing_uid]
raise "Astro Thing UID '#{thing_uid}' not found" unless astro
prev_location = astro.configuration[:geolocation]
astro.configuration[:geolocation] = new_location
# IMPORTANT: reload the Thing
astro.disable
astro.enable
prev_location
end
# call it
new_location = "45.095002,-87.644520"
prev_location = update_astro_location("astro:sun:local", new_location)
logger.info "Astro's location updated from #{prev_location} to #{new_location}"
for those interested…
I dug a bit deeper and it seems, bindings automagically derive their Location from the system configuration - at least, if you used the auto-find option in the thing inbox.
So, you’ll only need to update one location for all (in my case I also have open meteo with the location).
how to automate via a "Location item"
- have some way to update the location (Owntracks, a “real” GPS, …) to an item
- have a rule firing regularly via cron - or if that item changes
- update system location
You could use either low-level API (ConfigurationAdmin) or REST-API. I decided to go with the first, because you don’t need to fiddle with API keys and stuff.
// get the state of the GPS item
var newPosition = items.getItem('WoMo_GPSPosition').state;
if (newPosition === null || newPosition.toString() === 'NULL' || newPosition.toString() === 'UNDEF') {
// if item state is null, abort
return;
}
// prepare low-level API
var osgi = require('openhab').osgi;
var Hashtable = Java.type('java.util.Hashtable');
var configAdmin = osgi.getService('org.osgi.service.cm.ConfigurationAdmin');
var config = configAdmin.getConfiguration('org.openhab.i18n', null);
// set properties
var props = config.getProperties();
if (props === null) {
props = new Hashtable();
}
// replace "location"-property with new GPS position
props.put('location', newPosition.toString());
config.update(props);
// write a short log-entry
console.info('System-Location updated: ' + newPosition.toString());
Yes, this is the “controversial feature”. It only works if the Thing UID is exactly what discovery would create, so in effect, it only works if the Thing was added from the Inbox.
I’m not sure if restarting the Thing is necessary, most bindings will deactivate/reinit by themselves whenever their configuration changes.
at least for Astro and open meteo a restart of the thing seems not necessary. It is not “immediately”, but in the next round of channel-refreshs it seems like the new location is used.
Just a little detail, Astro recalculates the new day’s event times at ten seconds after midnight. That’s your deadline for changing the location. I don’t know about OpenMeteo or the other weather bindings but I suspect they use the location on every poll of the service so they should pick up the change right away.
It’s actually 00:00:30 (I’ve been refactoring this logic). But, if the binding is reinitialized, as I think it is, the job is also run during initialization, whenever that is. So, it should be fine.
If you put the Astro binding into DEBUG, you can see when all the events are calculated, and should be able to verify that the update takes place as it should.
hmm… I experienced this:
2026-07-21 12:26:24.119 [INFO ] [scripting.rule.setzeAktuellePosition] - System-Location aktualisiert: 40.00,10.00
...
2026-07-21 12:27:23.029 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sonne_RiseStart' changed from 2026-07-21T05:33:51.567+0200 to 2026-07-21T05:38:17.969+0200 (source: org.openhab.core.thing$astro:sun:local:rise#start)
2026-07-21 12:27:23.035 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sonne_RiseEnd' changed from 2026-07-21T05:37:44.658+0200 to 2026-07-21T05:42:05.572+0200 (source: org.openhab.core.thing$astro:sun:local:rise#end)
2026-07-21 12:27:23.042 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sonne_SetStart' changed from 2026-07-21T21:08:05.955+0200 to 2026-07-21T21:05:56.895+0200 (source: org.openhab.core.thing$astro:sun:local:set#start)
2026-07-21 12:27:23.057 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sonne_SetEnd' changed from 2026-07-21T21:11:59.046+0200 to 2026-07-21T21:09:44.497+0200 (source: org.openhab.core.thing$astro:sun:local:set#end)
2026-07-21 12:27:23.059 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sonne_DaylightStart' changed from 2026-07-21T05:37:44.658+0200 to 2026-07-21T05:42:05.572+0200 (source: org.openhab.core.thing$astro:sun:local:daylight#start)
2026-07-21 12:27:23.062 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sonne_DaylightEnd' changed from 2026-07-21T21:08:05.955+0200 to 2026-07-21T21:05:56.895+0200 (source: org.openhab.core.thing$astro:sun:local:daylight#end)
...
I figured, if the sunrise/sunset items changed within a minute of changing the location, it would seem the channels are already using the new location?
As I said, I think both Thing reinit and recalculation are handled automatically.
Like @Nadahar said, the times will be calculated when the Thing initializes. In addition if it’s been running all day, it will recalculate the times 30 seconds after midnight (I was going from memory, something happens 10 seconds after midnight, or at least used to, but Astro apparently is 30 seconds after).
So the new times will be calculated:
- openHAB start up, sometime between start level 70 and 80
- when the Astro Thing is re-enabled (upon hitting “save” after a change in the UI, after re-enabling the Thing after disabling it) , I suspect when you change the location setting, the Thing gets reloaded
- 30 seconds after midnight
I only brought up the last one here to help time the triggering of the rule that changes the location so that you can get the new location in place before that scheduled daily calculation.
It’s a bit funny, I’ve been arguing in the past that I don’t see why having auto-update of the location is a point - that when people move, they usually restart OH anyway. But, I hadn’t thought of RVs…
And boats. There have been users who run OH on boats.
I think this has moved around a bit. After I refactored it, it doesn’t matter when it runs, because it now recalculates 26 hours ahead in time, and handles “deduplication” of events. But, before the refactoring, there was a “dead point” from midnight until the recalculation ran, where no events would take place.
ok, RVs and boats are somewhat edge cases. but valid ones, I guess. After posting this I do find quite a lot posts around RVs on the forum… 
The reason for arguing against it is that there are some very troublesome aspects of this auto-update, where it will sometimes overwrite what the user has intentionally configured. Since it’s “invisible” and can’t be enabled or disabled (the user must actually choose a ThingUID that either matches or mismatches that of discovery to “enable” or “disable” it), I had been arguing that we should limit it to where it’s actually needed, typically IP address and port, and then make it user controllable, not “magic”.
But, I’ve now learned that location too has a legitimate reason for participating. That doesn’t mean that I don’t think it should be made less “magic” and more controllable
hmmm… if it’s not too complicated, what about showing a “use system location” checkbox-option in the Thing. If it was auto detected, this could be the standard behaviour. If you just added the thing manually you can also click it.
that way, the connection would be visible in the thing - but yeah it has to be modelled from every binding/thing, that uses a location…
Yeah, and it’s not only about this property. We’d need to find a universal way to handle it, which is why I suggested first cutting it down to properties where it would actually be useful. What I imagined was a small checkbox or similar attached to properties where auto update was possible/potentially meaningful, which is why it should be narrowed down instead of appearing on every configuration property. But, the challenge remains how to do this without having to modify all the bindings.
The whole discussion is on ice at the moment, because nobody has come up with a suggestion that would actually be doable within reason.