I hear you both, problem is that I do not usually have log:set to DEBUG and the INFO level log probably won’t cut it? I remember I set up log4?? (cplus/java) a year back with my settings of log rotations etc, but an OH upgrade wiped it all, Should probably have done it using an override of some sort if that even exists.
As it is now, I only get one openhab.log, no rotation, so I don’t know how much debug logging it will hold.
I will try setting up rotation again, and keep it on during the night.
Back to the matter at hand:
when I tried to set AG1 to Controller -> still nothing heard when pressing S1
an a whim, I set AG2 (Basic set) to controller -> dimmer_switch1 triggered my rule
Coming to think of it, I did set that one last night as well. You know how it is burning the midnight oil …
I will throw out e DEBUG net tonight to see if we can catch anything.
On a side note Chris, HABMIN is acting up a bit. I had to set the AG in PaperUi. After attempting to do it in HABMIN, HABMIN showed the device with no active channels. Killing my Chrome browser tab and reloading HABMIN it appears OK again until trying to manipulate an AG.
At work, we use log4cplus , and we have log files for each log level. (FATAL+ERROR+WARN/LOG/DEBUG)
(Someone else set that up, so I’m that familiar with it.)
The DEBUG is set to log to a /tmpfs location (RAM-disk) so that the SSD is spared. (product with a 10yrs life span)
These logs do not survive a restart thought. Also, /tmpfs is linux specific.
Yeah, I’m not running on a pi with an SD card, so clearly leaving this on for a long time will further reduce the life of your SD card. I say further, because it’s inevitable that your SD card will fail. It’s just a matter of when…
In my config, I actually store the zwave log files outside of the openhab directory tree. I store 500 files because I occasionally need to look at trends, repeating errors, etc. over time. It also helps reduce backup time by keeping all but the current log file outside the openhab directory tree.
The target logfile directory did not match my system, and since my /opt is empty, nothing seemed to happen.
I changed these two lines, and the new logfile appeared automatically after my save:
Just noticed that 2 more switches, one other Fibaro dimmer-2 and one everspring, had stopped reporting back local ON/OFF switching.
Don’t know exactly when this happened.
I had to apply Controller to AG1 & AG2.
Funny thing was this time I only got it to work in HABMIN, but only after restarting my browser.
Anyhow, my Z-Wave debugging is on, so lets see what happens during the night.
Hello @chris, thanks for your help! At least Openhab 1.x - 2.3. I have used example for Fibaro Dimmer 2 switch_dimmer channel (0). It has worked correctly on previous version.
So now I changed .items configuration switch_dimmer to switch_dimmer1. Also I updated Openhab snapshot version to openHAB 2.4.0 Build #1404. After I updated newer version, I needed to reconfigure all zwave devices Lifeline to Controller. After that (fibaro dimmer 2) wall button work correctly. Item state from wall switch reported ON / OFF immediately.
Br,
Jussi
@chris I am also having the same problem since changing to version 2.4. The associated group is turned to node_1 on every reboot which includes updating the system to the latest snapshot every few days.
I have this currently randomly … every restart of openhab some devices stop working.
They get stuck at request nif or loose the association.
will do a debug and post it
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
98
This is also happening to me and I’m running OH2.3. Tried to change them to Controller but it reverts back to node_1. I’m running 2 types of zWave devices on my network. Not sure if this behavior is OK or NOT?
No problems for 15d now.
I too have noticed that Controller associations are listed as node_1 after a reboot, but things work OK.
Isn’t the Controller node #1 anyway?
I too experience this. But by itself the name in the GUI doesn’t really matter (node_1, controller or “” - as long as the controller receives reports everything is okay).