I’m confused. How did you get “mqtt:topic:8502933bd0:drivesensor:DrvMotStr”? You’ve shown me a Channel ID which you claim works. So just do what ever you did again on the other Channels to find their IDs too.
Just to be thorough:
If you are using MainUI to create the Links to the Items, or using “Add Equipment to Model” or “Add Points to Model” you never have to care about the actual Channel IDs. That’s handled for you.
The Channel in the UI has a little copy icon. Click that and it will copy the Channel ID to the clipboard.
So all of the old items are represented, but, of course show links to the old channel definitions. And display as invalid.
If I create a new channel with the UI and link the old item to it, it works. It is displayed with the old channel (which is marked invalid).
The difference being the UID. If I understand the UI creates the UID, I can’t change it. So, IF I wanted to use the old items file, I’d need to copy the the new channel with the icon you note and replace what’s currently in the items file.
I assume the lock icon on all the old items is because they came from the file and the addition of the new channels won’t be persisted?
As for the mail, I’m at a loss then. The thing name is the same as that shown above in the getActions call.
Sigh, you helped me set all this up years ago, and I guess I should have taken far more copious notes, I haven’t even scratched the surface, with persistence, presence, and time of day stuff…clearly I’ve forgotten more than I remember.
Once the Thing is created then yes, you cannot change it. But when you first create the Thing you have the option to set the ID to some degree. However, a Thing ID is a combination of the Broker Thing’s ID, the Generic Thing’s ID, and the Channel ID. So if you need to match the IDs you had before you’d have to recreate everything. But this time instead of using what ever gets randomly put in you should supply the ID that matches your old one.
Yes
It’s probably a new feature in OH 3.1 which I believe is being released at the end of next week.
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.
