Hi @geedsen!
Looks like you did a lot of work to compile HG to .Net Core!
I was able to compile your solution on MacBook, but it fails in runtime with System.PlatformNotSupportedException (looks like OpenSource.UPnP.UPnPDevice.CreateRootDevice() method calls System.Net.NetworkInformation.BsdNetworkInterface.get_IsReceiveOnly() which is not supported). It’s OK as a couple of years ago I faced a similar issue with Mono runtime on MacBook and simply disabled UPnP interface during local debugging. It may be easier to find .net core compatible UPnP library.
A lot of users are running HG on Linux boxes like RaspberryPi, and also I propagandize the use of Docker so I think the movement to .Net Core platform should be done with attention to *nix systems.
Also, I think it’s better to use my fork of HG as I did a lot things since original HG development has stopped: updated a lot of packages, replaced platform-specific SQLite with managed LiteDB, refactored folder structure to make HG ready for running inside a docker container, build docker images for x86 and Arm architectures, refactored some “controllers” to split 1000-lines methods , crafted installation scripts for docker and regular installations and so on. Take a look at https://github.com/Bounz/HomeGenie-BE/releases and https://homegenie.club/c/dev/releases/14.
But after that I became a father and development have stopped
I had some muzzy plan about the transition to .Net Core and wasn’t able to implement it:
Make SerialPortLib .Net Core ready (created PR a month ago https://github.com/genielabs/serialport-lib-dotnet/pull/17 but can’t merge it without Gene, maybe it’s time to create own NuGet package for this lib, but I don’t like to increase entropy with different packages)
Make MIG interface libraries using SerialPortLib .Net Core Ready
Make HG .Net Core ready
…
Profit!
Create docker images for .Net Core
But after that, I had a lot of thoughts about HG architecture and code, and as you could see, it’s ugly. Also, the whole frontend part should be rewritten from scratch, as it’s a formidable task to support all this jQuery Mobile UI.
So these are my thoughts about the project and I would be glad to hear what you think.
All I can say is it would be great if someone with the requisite experience would take this project and bring it on to the next level. It’s frozen in time at the moment and posting requests in Githubs appears to be a complete waste of time.
I imagine where we are now that the target market for HG would be Linux on a single board computer, particularly Raspbian on the Raspberry Pi.
As @Bounz has gone to the trouble of setting up a forum and forked the original project and of course is still active, I agree that any new work should be based around the BE version of the HG project. Either way it is fantastic to see @geedsen take on this challenge.
@Bounz I will have a look at your version. Does it differ a lot from the version I started off with? I just fixed some issues this evening. And I am getting further. But still dont fully understand how it works. For example the compilation works , I see a whole bunch of programs appearing in the ‘/programs’ directory. But haven’t figured out if the build is triggered every start or … (maybe I changed something that causes it). Also I see that creating instances like ScriptInstance fails as I don’t have parameterless constructors. I would like to remove the Activator.CreateInstance from the code and use DI to ‘GetService’ instead. But that would mean I would need to load the assemblies at startup in the DI container. So I don’t know how that would work as it first has to build them… was/is there an automatic restart or something after the build? Anyway I am a Windows developer…but my goal of course is that it will run on my RaspberryPi. And I agree, it’s ugly. And perhaps that is because of the complexity. I really would like to have a picture /diagram of what is what and what is its purpose. And then see if we can make them separate , independent modules. Possible we should have a REST api that can be used to address the backend and then the frontend can use that. Which can be a website, but also an App (xamarin?). The thing is that I also have limited time available. So this is not something I can do on my own. Who else can help out here? I believe there is a lot of potential here…
I think you have identified the biggest problem here. Lack of time available to dedicate to an undertaking like this. You can see from the original forum http://old.homegenie.club:8080/www.homegenie.it/forum/index.html where the project was going before the original author halted development.
There were quite a few members on the original forum who had similar skill sets to yourself but have since drifted away for various reasons. Maybe if you put a call out to other forum members you may reach someone who is willing to collaborate with you.
It is ironic that you are a Windows developer as clearly that’s where HG’s roots lie. In terms of home automation these days the emphasis seems to lie on the side of Linux but again I may be wrong.
At least Bounz has been able to test your efforts so far, albeit on the Mac platform but I think that’s a good starting point for you.
If you do get a chance to publish your project for the ARM processor I would be only too glad to provide you with some feedback.
My fork differs from the original one, not significant, but in a bunch of small details, solution structure, updated libraries, a couple of rewritten modules.
Yes, programs are rebuilding at system startup (look at HomeGenieService.cs:939) to ensure they are ready to run during automation events. Also, this allows you to compile the user automation program once and then save resulting assembly on disk to speed up the next system load.
About DI and dynamic assembly loading.
I think it’s impossible to get rid of dynamic assembly loading because of the extendable nature of the system. Every MIG module can be easily plugged in (there is also UI for getting modules from the repository), and also compiled user automation programs have dynamic nature and couldn’t be statically defined during the compilation of the main system.
But internal services of HG, of course, should be registered in DI and used accordingly.
I can help a little bit, but also have a very limited time for myself at all =))
P.S. Found an article about how to dynamically compile load and unload assemblies in .Net Core 3.0 and correlated documentation AssemblyLoadContext class. The later one should be useful with loading and unloading MIG interfaces.
I was curious if this effort to convert HG to using .NET Core has made any further progress or if those involved have drifted on to new projects? I am still running an ancient version of HG on my RPI and had been looking forward to some new inspiration on the platform to hopefully add new enthusiasm for the project!
I am sorry. Time is a problem for me. I wish I had more time to spent on these kind of things. I am renovating a farm and that takes most of my free time. If there would be an actual active team of developers here that would all dedicate some of their time, I think I would join is as well. But I am afraid that that is not the case. Sorry again.
Well that all looks very positive now. Great to see that potential level of collaboration finally. This new effort could certainly give the likes of Home Assistant a run for their money.
I have to admit I always had a fondness for HG and while I moved much of my automation needs over to Home Assistant over a period that particular project has developed into a headless horse going in all different directions. Maybe HG can now reclaim its user base in light of these recent proposals.
You were such a prolific contributor to the HG project and your efforts enabled the project to sustain through the lean period. Now that Gene is back developing I’m really looking forward to this new energy and hopefully others who previously contributed in a technical form will be back along with other new and energetic coders to join forces.
, crafted installation scripts for docker and regular installations and so on. Take a look at https://github.com/Bounz/HomeGenie-BE/releases and https://homegenie.club/c/dev/releases/14.
