Email notification-could we have a closer look at this

Problems with sending email notifications have been on on going problem for Homegenie users throughout the various releases of Linux, particularly Raspberry Pi users on Raspbian. They were working on Wheezy then stopped. Some are having problems in Jessie. For me Stretch is sending emails at the moment but I don’t know how long that will last.

The problems always seem to relate to SSL security certs. Updates to the Mono project seem to trigger these problems. I am currently using email notification in a different application and have never had problems with this. All we are trying to do is have Homegenie send an email to a specified address. In that other application I’m running I use Port 25 with no SSL yet Homegenie will not send an email using Port 25. It only allows us to use Port 587 with SSL and insists on credentials verification.

Does anyone know why email sending was implemented in this way. Could we have another look at how email sending is implemented in Homegenie and maybe we could redesign this feature so it will work for everyone.

Actually, you should be able to send an email without SSL if your SMTP server allows insecure connections and your ISP doesn’t block 25 port.
But I agree, sometimes these email related problems look very confusing.
And as far as I know it’s somehow possible to bypass SSL verification, but this invalidates the whole idea of SSL.
I hope that .Net Core (if we will be able to migrate from mono) will be more stable in terms of working with emails.

when you say “migrate from Mono” what do you intend to migrate to/

.Net Core (

Interesting article.

A lot of pros and cons for the options available. Being a Linux user I like the look of Golang (but I would say that). I’m thinking a rewrite rather than a migration could possibly be an easier option but either way it’s a large undertaking.

What do you think would be the timescale for an undertaking like this Bounz

Yes, Go is very interesting language. It statically compiles code into a single binary that may be easily distributed. But it lacks the ability to compile code at runtime and this is how automation programs work in HG.

I have been thinking about rewriting the system from scratch since October but haven’t made a decision yet. It has its own pros and cons. But because I have a full-time job, a family and other hobbies aside from programming, I understand that I’ll be very be tied for time.
That’s why I decided to make a form of HomeGenie - it’s easier to refactor some things than rewrite them from scratch.

I’m going to continue experiments that may move the project closer to migrating to .Net Core. Right now it’s not possible because HG has dependencies from a number libraries, which are not compatible with .Net Core.

Maybe that’s what Gene meant when he said it was a finished product. Finished in the sense that it couldn’t be taken any further forward in its current format. As you know a product like this cannot stand still. It needs to evolve and adapt.

Holding down a full time job and maintaining and refactoring a home automation product like this is quite a difficult thing to do. Users need to understand this and be patient with their requests for solutions.

Hopefully others with the relevant experience can climb on board and assist you with this project. Your forward thinking approach should help bring this project to a new level.