HomeGenie 1.2-Stable-32

Thank you, backup and running with:

homegenie_1.2-beta.17_all.deb

John

Anyone using newest ver 34? Any issues?

Yes and no is the simple answer.

Sweet. thanks. Altho I have not seen any release notes addressing security device module reporting issue, I may try it.

Gene hasn’t supplied much in the line of info about each new release. except where issues were reported and some times not even there. :frowning_face:

Not being a user of x10 security devices what is the problem here. What errors do the logs report.

No errors were being reported on my end I suspect this was due to the security naming not being watched.

Ok so you’re showing no problems. @Mike what problem are you showing and please include a log so people have some idea what your problem is.

@mike if your having issues with the security console not reporting security device activity when they did before, check to be sure the security module was not disenabled during an HG update.
This happened to me once just re-enable it. Also be sure all modules are checked to use as a security sensor

He needs to post logs here so others can see what he is talking about. I’m looking at another users logs and he was showing issues with security modules with a log reporting
File not found exception /usr/local/bin/homegenie/lib/mig/x10_security_modules.xml

An updated version of Mono resolves the issue but I wouldn’t recommend this without first seeing the logs.

Yes I seen those logs as well but that user wasn’t complaining about security modules. I agree a posting of a log file might be helpful here. Checking to see if something is enabled or not might save time since I my self experienced it.

In most cases if the manual update and config restore process is used it avoids all these minor issues. I doubt the update issue will be a major consideration for now as the recent flurry of updates has settled down.

The main factor here is if a user has a problem with their install they post logs which are self explanatory. You don’t visit a doctor, tell him you have a problem, don’t give him the symptoms and expect a satisfactory diagnosis.

Since day 1, security modules have not populated with their names until after they sent one or more of their 20 minute check in sigs. Then if HG closed and reopened, it all starts afresh - no names on the modules; they just show as not really there. Nothing new; My question in other thread was to see if any of the updates ever addressed this issue. as it prevents me from terminating my AHP x10 other cm15 - when my alarm will not arm, or goes off in the middle of the nite, it is more than idle curiosity to find out exactly WHICH module is unhappy.

Thanks for reply tuicemen. Nothing new here. Just asked if it was addressed in the last year or so.

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.:roll_eyes:

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