Rest API, setting values

I knocked together a quick python script today to pull the values of a persistence group and convert it to a json file.

I’d now like to take that json file and set the values back to the items.

Is it just a put command with an item?

I’m doing it as every so often my map db dies and a bunch of default values do not get put back to their values.

Of course if I could read the map db I could check the values and or restore from git a good version.

I’ve found MapDB totally reliable, I’d be looking for the root cause rather than papering over it.

The REST API “docs” - actually an interactive demo / tool - are pretty good at showing what you need to do for whichever action. Have you played with this?

Under what circumstances? Is this a restore-on-startup problem? There are known problems with the order of loading files in various versions of openHAB. Plus, bindings can interfere and overwrite restored values.

Do the other night I had an issue with my alarm monitoring. OpenHAB is on the same machine, and so I wanted to restart it.

So I ssh’d into Karaf and ordered a shutdown. Because it’s docker based when you order a shutdown it seems to restart the container

So after what I thought was a suitable time it did a system restart.

Upon coming back some of my restore on start up vales were not set. So there’s a bunch I need to set for my heating and lighting to work

So I looked at fixing the actual problem rather than a bandaid.

I use docker. Originally I had the compose restart condition set to “always”. And when I get into karaf and enter a system:shutdown, I see the container restart. So I tried changing the container defintion to “unless-stopped” and I see the same thing.

2020-01-22T20:01:02.107277018Z 	at su.litvak.chromecast.api.v2.ChromeCast.getMediaStatus(
2020-01-22T20:01:02.107295192Z 	at org.openhab.binding.chromecast.internal.ChromecastCommander.handleRefresh(
2020-01-22T20:01:02.107312884Z 	at org.openhab.binding.chromecast.handler.ChromecastHandler$Coordinator$
2020-01-22T20:01:02.107415805Z 	at java.util.concurrent.Executors$
2020-01-22T20:01:02.107436542Z 	at java.util.concurrent.FutureTask.runAndReset(
2020-01-22T20:01:02.107453121Z 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(
2020-01-22T20:01:02.107551048Z 	at java.util.concurrent.ScheduledThreadPoolExecutor$
2020-01-22T20:01:02.107579133Z 	at java.util.concurrent.ThreadPoolExecutor.runWorker(
2020-01-22T20:01:02.107666852Z 	at java.util.concurrent.ThreadPoolExecutor$
2020-01-22T20:01:02.107685342Z 	at
2020-01-22T20:01:35.307801819Z ++ test -t 0
2020-01-22T20:01:35.307871531Z ++ echo false
2020-01-22T20:01:35.307992396Z + interactive=false
2020-01-22T20:01:35.308042896Z + set -euo pipefail
2020-01-22T20:01:35.308058712Z + IFS='
2020-01-22T20:01:35.308148694Z 	'
2020-01-22T20:01:35.308257131Z + '[' limited = unlimited ']'
2020-01-22T20:01:35.308453801Z + rm -f /openhab/runtime/instances/
2020-01-22T20:01:35.312066014Z + rm -f /openhab/userdata/tmp/instances/
2020-01-22T20:01:35.314698782Z + NEW_USER_ID=1000
2020-01-22T20:01:35.314736099Z + NEW_GROUP_ID=1001
2020-01-22T20:01:35.314782122Z + echo 'Starting with openhab user id: 1000 and group id: 1001'
2020-01-22T20:01:35.314931527Z Starting with openhab user id: 1000 and group id: 1001
2020-01-22T20:01:35.315331139Z + id -u openhab
2020-01-22T20:01:35.321994005Z + case ${OPENHAB_VERSION} in
2020-01-22T20:01:35.322965095Z ++ ls -A /openhab/userdata
2020-01-22T20:01:35.326520191Z + '[' -z 'cache
2020-01-22T20:01:35.326573595Z config
2020-01-22T20:01:35.326595058Z etc
2020-01-22T20:01:35.326611416Z jsondb
2020-01-22T20:01:35.326627833Z logs
2020-01-22T20:01:35.326649871Z persistence
2020-01-22T20:01:35.326668405Z temp
2020-01-22T20:01:35.326683671Z tmp
2020-01-22T20:01:35.326700113Z zwave' ']'
2020-01-22T20:01:35.327729180Z ++ cmp /openhab/userdata/etc/ /openhab/userdata.dist/etc/
2020-01-22T20:01:35.330909818Z + '[' '!' -z ']'
2020-01-22T20:01:35.331991416Z ++ ls -A /openhab/conf
2020-01-22T20:01:35.336149738Z + '[' -z 'a.out
2020-01-22T20:01:35.336199572Z .git
2020-01-22T20:01:35.336211954Z .gitattributes
2020-01-22T20:01:35.336223732Z html
2020-01-22T20:01:35.336234812Z icons
2020-01-22T20:01:35.336246043Z items
2020-01-22T20:01:35.336257008Z persistence
2020-01-22T20:01:35.336268378Z README.txt
2020-01-22T20:01:35.336279761Z rules
2020-01-22T20:01:35.336290544Z scripts
2020-01-22T20:01:35.336301455Z services
2020-01-22T20:01:35.336312443Z sitemaps
2020-01-22T20:01:35.336323094Z sounds
2020-01-22T20:01:35.336333785Z things
2020-01-22T20:01:35.336346517Z transform' ']'
2020-01-22T20:01:35.336409994Z + chown -R openhab:openhab /openhab
2020-01-22T20:01:35.470491001Z + sync
2020-01-22T20:01:35.558968562Z + '[' -d /etc/cont-init.d ']'
2020-01-22T20:01:35.559049583Z + sync
2020-01-22T20:01:35.611494739Z + '[' false == false ']'
2020-01-22T20:01:35.612797451Z ++ IFS=' '
2020-01-22T20:01:35.612867658Z ++ echo gosu openhab tini -s ./
2020-01-22T20:01:35.613775429Z + '[' 'gosu openhab tini -s ./' == 'gosu openhab tini -s ./' ']'
2020-01-22T20:01:35.613806891Z + command=($@ server)
2020-01-22T20:01:35.613999519Z + exec gosu openhab tini -s ./ server
2020-01-22T20:01:35.626036214Z Launching the openHAB runtime...

The errors are a disconnection, crash from the chromecast as it’s going down…then you see it instantly start recreating the container and starting again.

How can I gracefully stop openhab + the container so that the mapdb is not corrupted?

I see in here that they changed to using tini to start the container (not sure what that does), and while I see that being used on my 2.3 version, I still get the java process being restarted after I call a system:shutdown

You might want to change your thread title and tags if you want to get the attention of Docker knowledgeable types.

Continued Here: