Well, I guess EVERY step of this process is going to be a PITA.
I added the Zwave binding set the serial port (/dev/ttyAMA0) and clicked add thing.
Error: controller offline.
Checked the privileges on the /de/ttyAMA0 group is set to RW for dialout. openhabian is a member of dialout.
For the Things names, the UI adds a UID to the ID, before anything I enter, so the new name can’t match the old names…unless I’m missing something, which s probably the case.
So, it seems the AEOTEC Z-Stick is NOT fully USB compliant (as I found from other posts here that led me to the discussion on the Pi forums…) and the Pi 4 USB controller doesn’t like it.
So, I plugged the SD card into my Pi3, and /dev/ttyACM0 shows up immediately and then the binding/Thing see it and it comes online and begins finding the all my Z-wave devices.
You can change all the things with the red arrow prior to clicking “Create Thing”.
You’ve said earlier that you learn better by manipulating something to see how it works. Try applying some of that approach here as well. Click on stuff. Change things and see what happened. Experiment and explore.
Couldn’t figure out why an item was not initialized in a rule that had been working for years under OH2.x.
The following line get a can’t cast NULL: val tc = Motion_Count.state as Number + 1
But the column number it gives is the ‘a’ in ‘val’. But, I’m prett sure it means Motion_Count.state is NULL.
Couldn’t find a rule that ran at startup (thought I did have one at one time…).
Couldn’t find it being persisted in the influx of map db.
So, confused on that. Any ideas appreciated.
Speaking of persistence.
Is there a way to get use my old influx db file after I install influx on the OH3.x system?
Same question for mapdb? (Edit: did some searching in the forum…is mapdb not going to be supported? Couple of forum post note Infux isn’t suited for restore on startup purposes?)
And rrd4j …
Log keeps showing: Could not create rrd4j database file '/var/lib/openhab/persistence/rrd4j/mqtt_inlet_temp.rrd': Read failed, file /var/lib/openhab/persistence/rrd4j/mqtt_inlet_temp.rrd not mapped for I/O
So, there’s no reason to think it won’t still be NULL? All Items are created with state NULL and that’s the way they stay, unless restored by persistence (which would necessitate having a non-NULL state in the past), poked by a rule, or poked by a binding.
It’s up to you, which are you expecting to have happened?
Might be useful -
It is very hard to keep my current frustration level from coming through in my posts and my responses.
I have been trying to get this system back running for, now, 4 days.
I had a OH2 system that I did a LOT of configuration with YEARS ago. (Read: I have forgotten a lot of what I did).
It had a InfuxDB, it had a Mapdb. I suspect one of those was persisting this particular value.
Every minute or so the log spews 100 or so lines like this, one for each item: Could not create rrd4j database file '/var/lib/openhab/persistence/rrd4j/TheaterScene.rrd': Read failed, file /var/lib/openhab/persistence/rrd4j/TheaterScene.rrd not mapped for I/O
Unfortunately, the OH2 system is not functional and all I have to see what it did is the SD card.
I now have a OH3 system. It is not persisting ANYTHING. I have no idea why rrd4j says none of the files are mapped for I/O. I have not installed Influx…I have no idea how, or if, I can use the old Influx db files. Mapdb appears to have disappeared in OH3.
And that Motion_Count isn’t listed in any of the .persist files (mapdb and influxdb) of the old system.
So, to answer your question, I don’t know what I expect or need. I don’t know how it worked before. But, since the rule worked for years…I have reason to expect it was being set other than NULL somehow.
The OH3 system time is 6 hours off, but, my ntp time is right, the zwave devices are all working, as are the mqtt nodes and the system can send email. So at least I have something to show for 4 days worth of head banging.
Fair enough. But if you have no idea how the moving parts of your system work together, there’s not likely to be much help to found here.
Maybe your mystery counter gets updated by some rule depending on Items you haven’t got working yet. We can’t say, you could find out, you might just put it off as the least of worries.
Go one step at a time - what’s your major obstacle right now?
Logs are timestamped according to Java time clock. openHABs clock is derived from that, but setting openHABs timezone does not get fed backwards to Java. Set your Java timezone/locale.
hmm…I’m sure you are correct, I dug around the forum a bit and even read some posts you made, but there doesn’t seem to be a definitive “do this to set the java time”. Lots of “I did this”, “that didn’t work for me, I did this”…
Local time: Sun 2021-06-27 09:49:09 CEST
Universal time: Sun 2021-06-27 07:49:09 UTC
RTC time: Sun 2021-06-27 07:49:12
Time zone: Europe/Berlin (CEST, +0200)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
Local time: Sun 2021-06-27 13:40:22 CEST
Universal time: Sun 2021-06-27 11:40:22 UTC
RTC time: n/a
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Noted “NTP service: active” is different from yours “NTP synchronized: yes”.
Sigh, so in the mean time I looked to see if ntp was installed. Apt said no, so I installed.
Now timedatectl shows:
Universal time: Sun 2021-06-27 12:21:47 UTC
RTC time: n/a
Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
so now it looks like the system is set to the right timezone, but not using NTP?
Edit: It now says:
Universal time: Sun 2021-06-27 12:31:04 UTC
RTC time: n/a
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
The host operating system has a clock - and a timezone.
The Java sub-system has a clock- and a timezone. When you install Java, it guesses timezone based on OS timezone, unless you tell it different. If you later amend the OS timezone, I do not think it changes Java. This is the clock the logger uses.
openHAB application has a clock and a timezone. When you install OH, it guesses timezone based on Java timezone, unless you tell it different. If you later amend the OH timezone, it does not change Java. If you did have to amend OH, it’s a good clue the Java timezone was not what you wanted.
Don’t forget we still do not know what timezone you think is wanted.