The module names do populate prior to checking in now on a reboot or the web UI being closed and reopened. I believe a backup needs to be done to write the info to HG, interestingly writing a backup doesn’t write the info to the backup however a second backup does.
And that’s exactly why I suggested posting logs. Saves confusion trying to identify what exactly the problem is.
If @mike chooses not to post logs I doubt he will resolve his problem as X10 security modules wouldn’t be too popular in HG. On the other hand a quick glimpse at the log report by an experienced user would probably yield a solution.
There is no reason to post a log file if a user is running a old version that did not have the option. Since mike has not stated he still has the issue with the latest build we can only assume the issue he had is solved.
Users realy should at least try the latest builds of any software they use. Reverting back to an old build if the newest HG is unstable isn’t that hard.
There’s always been a facility for logging in HG. You’ll find it in the Settings section. It can be turned off or on as the case requires.
Messing about trying to guess a users problems really is a waste of time. While some may think they have identified the problem without them, other issues can be at play that may be masking the main issue.
In fairness that’s why the logging system was introduced in the first place. Any serious designer/programmer wouldn’t design an application without one.
In Raspbian a simple grep content to log file will perform all the logging you need but the application has this facility built in.
I totaly agree however if like the case with security modules not displaying their names till they checked in was not a bug. It was by design (as Gene explained to me) prior to recent builds. Users realy should be testing updates rather then asking if something was fixed prior to updating. In this case nothing would show up in a debug if done in a version that was working as designed.
Not everyone wants to be an early adopter or a tester. Some are happy enough to remain on a version that works stable and reliably for them. I believe some are still on early version r50x and are happy enough to run with that.
The solution for users who are experiencing issues like this is to bring it to the attention of the GitHub maintainer, Bounz for the BE forked version or Gene for his. Others then can clearly see the progression being made on these issues and if and when they are resolved.
I will say though it’s not good enough to say you have a problem, give a brief description of it and hope somebody magically resolves it for you. Support is a two way thing here.
1 Like