Best choise for a controller
-
@dzjr said in Best choise for a controller:
@rejoe2 I had never looked at FHEM myself, I will certainly do so.
As a server, I also received a tip to use an Intel nuc instead of a Pi.
Have a look at Linux compability first when looking for Intel NUC. My HA system runs on a ThinClient platform from hp. Consumes slightly more than a Pi or newer NUC, but only costs around the same as a new Pi.
Wrt. to what @monte said about Home Assistant: Comparing is not really easy, as one can focus on different things, but most likely FHEM might stand the test, especially if you focus on hardware integration and automation (but to be honest: Perl on which FHEM is based is "special" and seems to be no longer "a la mode").
If you are able to read German, you can find some infos on FHEM compared to OpenHAB and IOBroker here - there's also some few remarks from users with HASS experience (most of them highlight the shiny UI of HASS, and there are also some FHEM users going for FHEM for automation tasks and hardware interfacing and HASS as UI).@rejoe2 but is there anything that FHEM supports and HA doesn't?
Also keep in mind ongoing development in contrary to others (over 70 releases on github this year alone). For example google pulled off "works with nest" API, so many users can't use their thermostats with 3rd party software, but one of HA users made a simple dirty hack which makes it possible to integrate your nest thermostat for now, until google will release their new API for users.
Also HA is written in python which makes it pretty easy to fix any issues or add new features. -
Friends,
I ordered a mini PC anyway, and am going to try both HA and FHEM (maybe with a virtual OS), in addition to my current Domoticz system for the time being, and then see what works best for my situation.
What I had forgotten to say is that I will also use the controller to control the garden irrigation, of which I control the water valves and read the sensors with Mysensors, so I will certainly include the ease of scripting.
-
I have been using Domoticz (currently 4.10717) for a few years and it has always very stable except sometimes when the trouble is introduced by my mistakes. If you are satisfied with Domoticz, except for the current stability, I suggest it is something you can correct. Changing to another controller will be a lot of work.
I have had very good stability with Domoticz on rPI first, now on a basic Intel NUC running Ubuntu with SDD drive which is of course much faster.
Of course hardware trouble on the device running Domoticz is possible. I suggest using fastest, best quality hardware & SD card for your controller. Other software running on the same Pi might be causing your problem rather than Domoticz.
You can probably get better help debugging Domoticz on their forum.
A few ideas:
- Have you reviewed the Domoticz logs to identify any issues?
- I wonder why you are running two separate Domoticz controllers, and if a conflict could be causing problems? It may be easy for you to test by removing your second controller for a while.
Good luck!
-
Another option would be to run the controller on a virtual machine, which gives you a lot of conveniences. The usual scenario would be if you have, say, a vmware capable fileserver that's always on anyway, then adding a separate vm on it for your mysensors controller costs you nothing.
-
@grubstake Yes I know that building a new controller is a lot of work, but yes I prefer not to run beta anymore, and I understood that from stable to beta would not be a problem, but from beta to stable is very complicated, that's why I want to start again ...
The only thing I would like to take with me is the historical sensor data of certain (weather) sensors.
I have the second controller running because if I also run the second mysensors gateway on the first controller the controller crashes very quickly (every 3 to 4 hours), and then I have already completely disabled the modbus plugin.
I have searched on the domoticz forum, there is a call that the database is corrupt, but the SD card issue sounds more plausible to me afterwards.I'm going to try if I can run multiple virtual controllers on the new controller PC so that I can test it next to each other.
-
Another option would be to run the controller on a virtual machine, which gives you a lot of conveniences. The usual scenario would be if you have, say, a vmware capable fileserver that's always on anyway, then adding a separate vm on it for your mysensors controller costs you nothing.
-
@neverdie
Thank you for thinking along, I appreciate that!I already planned to build a virtual machine so that I could test / try several controllers next to each other.
@dzjr The ideal scenario, which may not fit your budget, would be a supermicro motherboard and an intel CPU that specifically supports virtual machines. Marry that to a capable UPS, and you'd have a commercial grade solution that would be rock solid and yet easy to maintain, even remotely. This way you have only one machine that needs backups, you need only one UPS, and the speed will likely be lightning fast. It probably only makes sense though in a scenario where you have other programs (file server, security cameras, or whatever) running 24/7 anyway. But if that's you, it's worth looking into.
-
@dzjr The ideal scenario, which may not fit your budget, would be a supermicro motherboard and an intel CPU that specifically supports virtual machines. Marry that to a capable UPS, and you'd have a commercial grade solution that would be rock solid and yet easy to maintain, even remotely. This way you have only one machine that needs backups, you need only one UPS, and the speed will likely be lightning fast. It probably only makes sense though in a scenario where you have other programs (file server, security cameras, or whatever) running 24/7 anyway. But if that's you, it's worth looking into.
@neverdie but isn't Docker more efficient and simple solution compared to a VM? Considering it will be used for single process anyway.
I have a combination of VM's, Docker and dedicated RPi's in my system and I learned that Docker has very little overhead compared to VM and has greater flexibility when it comes to backups, restores especially if there is ready to use image in the repository. -
@neverdie but isn't Docker more efficient and simple solution compared to a VM? Considering it will be used for single process anyway.
I have a combination of VM's, Docker and dedicated RPi's in my system and I learned that Docker has very little overhead compared to VM and has greater flexibility when it comes to backups, restores especially if there is ready to use image in the repository. -
@rejoe2 but is there anything that FHEM supports and HA doesn't?
Also keep in mind ongoing development in contrary to others (over 70 releases on github this year alone). For example google pulled off "works with nest" API, so many users can't use their thermostats with 3rd party software, but one of HA users made a simple dirty hack which makes it possible to integrate your nest thermostat for now, until google will release their new API for users.
Also HA is written in python which makes it pretty easy to fix any issues or add new features.@monte said in Best choise for a controller:
@rejoe2 but is there anything that FHEM supports and HA doesn't?
As I'm not familiar with HA, it's rather hard to give a valid answer to this question. As already mentionned, FHEM is strong in hardware integration, so eg. SOMFY shutters might be an example. In general, FHEM gives the option to run a cloudfree HA system, so the need for external (especially google) software to steer some thermostats rather sounds ridiculous to me - FHEM especially is able to control Z-Wave, EnOcean, MAX and HomeMatic (not "-IP") hardware with just an USB dongle for each of these wireless protocolls; my ZigBee installation just uses some piece of software running on the same server hardware and also an USB dongle.
Also FHEM provides some modules for "easy" configuration of typical HA tasks like shutters control (taking into account a lot of stuff like sunrise/sunset, internal/external temperatures, shading needs, individual's presence...) or heating control. Don't know what HA provides in that direction, though.
Also keep in mind ongoing development in contrary to others (over 70 releases on github this year alone). For example google pulled off "works with nest" API, so many users can't use their thermostats with 3rd party software, but one of HA users made a simple dirty hack which makes it possible to integrate your nest thermostat for now, until google will release their new API for users.
FHEM is also under ongoing development, but follows a different release strategy, it's more like a perpetual beta, so updates can not be counted in "releases". If you install the current debian package with release 5.9 and do an update (from within FHEM), you will get around 2.000 commits applied since the release of 5.9 and still be on feature level 5.9. Additionally to mentionned that: the most of the commits not affecting the core part, which is rather stable.
If you opt for the docker version, you will get an up-to date system just from the first second.Also HA is written in python which makes it pretty easy to fix any issues or add new features.
Python might be more common than Perl these days, but wrt. to that point there's no further significant difference between the two.
Wrt. to bugfixing and reaction to changes "to the outer world" also an example: When yahoo closed down it's weather service (afaik, they didn't prewarn), it took around 4 weeks until there was a different solution provided - without need to do a lot of changes for those users who used the data within their FHEM installations - they had e.g. just to get a key from darksky and change the data source (but internally the code structure had been rebased to be much more flexible for the future).
Controller: FHEM; MySensors: 2.3.1, RS485,nRF24,RFM69, serial Gateways
-
@monte said in Best choise for a controller:
@rejoe2 but is there anything that FHEM supports and HA doesn't?
As I'm not familiar with HA, it's rather hard to give a valid answer to this question. As already mentionned, FHEM is strong in hardware integration, so eg. SOMFY shutters might be an example. In general, FHEM gives the option to run a cloudfree HA system, so the need for external (especially google) software to steer some thermostats rather sounds ridiculous to me - FHEM especially is able to control Z-Wave, EnOcean, MAX and HomeMatic (not "-IP") hardware with just an USB dongle for each of these wireless protocolls; my ZigBee installation just uses some piece of software running on the same server hardware and also an USB dongle.
Also FHEM provides some modules for "easy" configuration of typical HA tasks like shutters control (taking into account a lot of stuff like sunrise/sunset, internal/external temperatures, shading needs, individual's presence...) or heating control. Don't know what HA provides in that direction, though.
Also keep in mind ongoing development in contrary to others (over 70 releases on github this year alone). For example google pulled off "works with nest" API, so many users can't use their thermostats with 3rd party software, but one of HA users made a simple dirty hack which makes it possible to integrate your nest thermostat for now, until google will release their new API for users.
FHEM is also under ongoing development, but follows a different release strategy, it's more like a perpetual beta, so updates can not be counted in "releases". If you install the current debian package with release 5.9 and do an update (from within FHEM), you will get around 2.000 commits applied since the release of 5.9 and still be on feature level 5.9. Additionally to mentionned that: the most of the commits not affecting the core part, which is rather stable.
If you opt for the docker version, you will get an up-to date system just from the first second.Also HA is written in python which makes it pretty easy to fix any issues or add new features.
Python might be more common than Perl these days, but wrt. to that point there's no further significant difference between the two.
Wrt. to bugfixing and reaction to changes "to the outer world" also an example: When yahoo closed down it's weather service (afaik, they didn't prewarn), it took around 4 weeks until there was a different solution provided - without need to do a lot of changes for those users who used the data within their FHEM installations - they had e.g. just to get a key from darksky and change the data source (but internally the code structure had been rebased to be much more flexible for the future).
@rejoe2 that's exactly what I am talking about. HA is "cloudfree" home automation system. You can run everything locally without any connection to the internet, unless you want to use something that works ONLY via web API like google nest.
I suggest you take a look at this list https://www.home-assistant.io/integrations/. HA works with dongles and local gateways if they are available, it even has KNX integration which was crucial for one of my projects. -
@monte
OK, so let's concluse: FHEM and HA seem to have at about the same functionality - FHEM amongst others also supports KNX.
It's up to the TE (and whoever may read this in the future) to decide what to prefer - I'll stick to FHEM which I'm now pretty familiar with... -
I have the new server running with VirtualBox from Oracle as a virtual machine host.
Luckily I found an explanation via google to install hassio via VirtualBox, it was a bit more work than I had expected to build the server ...
I also have FHEM running on a Virtual machine, and to be honest it is not what I am looking for, among other things FHEM does not see the sensor names in the presentation, so this will all have to be set manually, and further I saw that you have to set a lot by hand.
Now that is not a problem, but compared to another controller that is a downside I think, but I am probably going too short.I also run Home Assistant, although I had a considerable crash, so I reinstalled the hassio.
I think H-A is pretty powerful, many integrations, as HA saw Ikea lamps and Sonos at the same time.I have already added a MySensors gateway (the test gateway on my desk) but I did not immediately see the sensors appear in HA, so that is something I have to figure out.
At the moment I am still in doubt between Domoticz and HA, where Domoticz has the advantage that the MySensors sensors can be added very easily by setting it in the hardware menu and then you can also monitor them immediately.
However, I find the coarse web interface of domoticz a little less.If I completely switch to HA, then really not until I have thoroughly immersed myself in it, so a lot of reading work ...
dzjr
-
I have the new server running with VirtualBox from Oracle as a virtual machine host.
Luckily I found an explanation via google to install hassio via VirtualBox, it was a bit more work than I had expected to build the server ...
I also have FHEM running on a Virtual machine, and to be honest it is not what I am looking for, among other things FHEM does not see the sensor names in the presentation, so this will all have to be set manually, and further I saw that you have to set a lot by hand.
Now that is not a problem, but compared to another controller that is a downside I think, but I am probably going too short.I also run Home Assistant, although I had a considerable crash, so I reinstalled the hassio.
I think H-A is pretty powerful, many integrations, as HA saw Ikea lamps and Sonos at the same time.I have already added a MySensors gateway (the test gateway on my desk) but I did not immediately see the sensors appear in HA, so that is something I have to figure out.
At the moment I am still in doubt between Domoticz and HA, where Domoticz has the advantage that the MySensors sensors can be added very easily by setting it in the hardware menu and then you can also monitor them immediately.
However, I find the coarse web interface of domoticz a little less.If I completely switch to HA, then really not until I have thoroughly immersed myself in it, so a lot of reading work ...
dzjr
@dzjr said in Best choise for a controller:
I have already added a MySensors gateway (the test gateway on my desk) but I did not immediately see the sensors appear in HA
Pay attention to "Presentation" paragraph. "Send at least one initial value per V_TYPE. In version 2.x of MySensors, this has to be done in the loop function." And there is example code below. I had the same problem when first tried HA with Mysensors.
I used Domoticz for 4 years and I like how everything is configurable through web UI, but lack of development and lack of deep customizations made me looking forward to switch to HA.
-
I have the new server running with VirtualBox from Oracle as a virtual machine host.
Luckily I found an explanation via google to install hassio via VirtualBox, it was a bit more work than I had expected to build the server ...
I also have FHEM running on a Virtual machine, and to be honest it is not what I am looking for, among other things FHEM does not see the sensor names in the presentation, so this will all have to be set manually, and further I saw that you have to set a lot by hand.
Now that is not a problem, but compared to another controller that is a downside I think, but I am probably going too short.I also run Home Assistant, although I had a considerable crash, so I reinstalled the hassio.
I think H-A is pretty powerful, many integrations, as HA saw Ikea lamps and Sonos at the same time.I have already added a MySensors gateway (the test gateway on my desk) but I did not immediately see the sensors appear in HA, so that is something I have to figure out.
At the moment I am still in doubt between Domoticz and HA, where Domoticz has the advantage that the MySensors sensors can be added very easily by setting it in the hardware menu and then you can also monitor them immediately.
However, I find the coarse web interface of domoticz a little less.If I completely switch to HA, then really not until I have thoroughly immersed myself in it, so a lot of reading work ...
dzjr
@dzjr said in Best choise for a controller:
I also have FHEM running on a Virtual machine, and to be honest it is not what I am looking for, among other things FHEM does not see the sensor names in the presentation, so this will all have to be set manually, and further I saw that you have to set a lot by hand.
There's an option to derive the reading names from presentation info ("get <name> ReadingsFromComment"), but most likely you will not be satisfied with the result. But for sure, FHEM isn't an easy "mouse-based" system to understand and customize. On the other side it offers any option to do whatever you like within your system.
But anyhow: Thanks for having a look! -
@dzjr said in Best choise for a controller:
I have already added a MySensors gateway (the test gateway on my desk) but I did not immediately see the sensors appear in HA
Pay attention to "Presentation" paragraph. "Send at least one initial value per V_TYPE. In version 2.x of MySensors, this has to be done in the loop function." And there is example code below. I had the same problem when first tried HA with Mysensors.
I used Domoticz for 4 years and I like how everything is configurable through web UI, but lack of development and lack of deep customizations made me looking forward to switch to HA.
Sorry for the late response, I had some problems with a cheap Chinese solder board which I wanted to have solved first: P
I adjusted the sketch, as far as I understood it, I send a value for each V_TYPE, I now indeed see some more childs, but I don't see the relays / controls anywhere.
I also see the other sensors not yet in the device list, they are in the json file by the way, but that is confirmed by the presentation.Do I have to adjust some extras in HA for that?
-
@dzjr said in Best choise for a controller:
I also have FHEM running on a Virtual machine, and to be honest it is not what I am looking for, among other things FHEM does not see the sensor names in the presentation, so this will all have to be set manually, and further I saw that you have to set a lot by hand.
There's an option to derive the reading names from presentation info ("get <name> ReadingsFromComment"), but most likely you will not be satisfied with the result. But for sure, FHEM isn't an easy "mouse-based" system to understand and customize. On the other side it offers any option to do whatever you like within your system.
But anyhow: Thanks for having a look! -
Sorry for the late response, I had some problems with a cheap Chinese solder board which I wanted to have solved first: P
I adjusted the sketch, as far as I understood it, I send a value for each V_TYPE, I now indeed see some more childs, but I don't see the relays / controls anywhere.
I also see the other sensors not yet in the device list, they are in the json file by the way, but that is confirmed by the presentation.Do I have to adjust some extras in HA for that?
@dzjr sorry, it's hard to help in details, when I don't see actual sketch you are using. Please post complete sketch here, that's not workring as expected.
Also could you explain in details what exactly working and what not? Does any Mysensors devices show in HA interface, or do you see them only in json file?
For relay you need to send V_STATUS message. You can try example sketch located in HA documentation and see if it's working. -
Thank you for your tip, unfortunately there are quite a few costs such as import duties .....
In the end I want to switch to a complete system, but after an afternoon of serving around I no longer know what I should and should not take .......
There is just a little too much choice in everything, and I don't want to take a risk with a second hand from a private person who might be broken or something.I think I'll start with the Pi4 for the time being, and add an SSD once.
@dzjr said in Best choise for a controller:
There is just a little too much choice in everything
I think you hit the nail on the head right here! :D I know I have been reading about all this stuff for years before starting, and I continue to read, and still keep learning more things all the time.
I think controller software is a highly personal preference, having to do a lot with functionality, learning curve, what language it may be written in, etc... I mean amongst the F/LOSS choices, anyway (which are the only ones I would ever consider).
After quite some research, I chose to use openHAB, which deserves it's reputation for having a big learning curve. But now that I am over that I feel there is nothing I cannot tie into it. I do not have experience with any of the others mentioned, so I cannot compare and don't have a strong opinion either way.
Something I do have much stronger opinions about, is hardware. :D I do not like to support Intel nor the Raspberry Pi "Foundation" because I strongly disagree with both of their business tactics.
In the case of Intel, they have been slow-rolling innovation and vastly overcharging for years. But what is much worse is that they were the ones who invented the modern bootloader level backdoor into your system with their Intel Management Engine (IME). They think it is not your device you bought with your hard earned money, but rather theirs. I am sorry but I find this highly offensive and refuse to purchase any more Intel hardware since I learned of this (AMD followed suit a few years later, see link, so I no longer buy their recent hardware, either).
The RPi "Foundation" isn't any better. Their proprietary boot loader runs first, and then loads your operating system. So your Linux (or whatever) is not really running the show. It can be throttled by the RTOS/bootloader. Totally obnoxious, the way they portray themselves as being "open source" etc. and everyone gobbles up this nonsense! Consequently, I refuse to buy their hardware, either...
And I have not even gotten into the stupid hardware decisions that were made on RPi, sharing the same bus with all the USB and Ethernet port. :face_with_rolling_eyes: It is absolutely unfit for the purpose of attaching eg., an SSH or HDD to and serving files over your network.
There are so many better choices than RPi nowadays from not only a freedom but also a performance (and reliability) standpoint.
I am sorry to have to be the one to get up on my soapbox :D but I think that all makers and hackers (pretty much everyone here) would do very well to not only educate ourselves on these issues, but also (I feel strongly, obviously :D ) vote with our feet and wallets for more open platforms! Competition is good for us, the little people. Look what has happened with Intel since AMD is no longer pushing them, now x86 is a totally lost cause from a freedom standpoint. The future I think is going to be ARM/RISC (maybe RISC-V if we are lucky!) but the future is shaping up right before our eyes. And we have a say in it! I encourage everyone to discuss platforms that are not only more actually open, but that give much greater performance per your hard earned {dollar/franc/euro/pound/etc.}! Here are some links to get started:
-
@dzjr said in Best choise for a controller:
There is just a little too much choice in everything
I think you hit the nail on the head right here! :D I know I have been reading about all this stuff for years before starting, and I continue to read, and still keep learning more things all the time.
I think controller software is a highly personal preference, having to do a lot with functionality, learning curve, what language it may be written in, etc... I mean amongst the F/LOSS choices, anyway (which are the only ones I would ever consider).
After quite some research, I chose to use openHAB, which deserves it's reputation for having a big learning curve. But now that I am over that I feel there is nothing I cannot tie into it. I do not have experience with any of the others mentioned, so I cannot compare and don't have a strong opinion either way.
Something I do have much stronger opinions about, is hardware. :D I do not like to support Intel nor the Raspberry Pi "Foundation" because I strongly disagree with both of their business tactics.
In the case of Intel, they have been slow-rolling innovation and vastly overcharging for years. But what is much worse is that they were the ones who invented the modern bootloader level backdoor into your system with their Intel Management Engine (IME). They think it is not your device you bought with your hard earned money, but rather theirs. I am sorry but I find this highly offensive and refuse to purchase any more Intel hardware since I learned of this (AMD followed suit a few years later, see link, so I no longer buy their recent hardware, either).
The RPi "Foundation" isn't any better. Their proprietary boot loader runs first, and then loads your operating system. So your Linux (or whatever) is not really running the show. It can be throttled by the RTOS/bootloader. Totally obnoxious, the way they portray themselves as being "open source" etc. and everyone gobbles up this nonsense! Consequently, I refuse to buy their hardware, either...
And I have not even gotten into the stupid hardware decisions that were made on RPi, sharing the same bus with all the USB and Ethernet port. :face_with_rolling_eyes: It is absolutely unfit for the purpose of attaching eg., an SSH or HDD to and serving files over your network.
There are so many better choices than RPi nowadays from not only a freedom but also a performance (and reliability) standpoint.
I am sorry to have to be the one to get up on my soapbox :D but I think that all makers and hackers (pretty much everyone here) would do very well to not only educate ourselves on these issues, but also (I feel strongly, obviously :D ) vote with our feet and wallets for more open platforms! Competition is good for us, the little people. Look what has happened with Intel since AMD is no longer pushing them, now x86 is a totally lost cause from a freedom standpoint. The future I think is going to be ARM/RISC (maybe RISC-V if we are lucky!) but the future is shaping up right before our eyes. And we have a say in it! I encourage everyone to discuss platforms that are not only more actually open, but that give much greater performance per your hard earned {dollar/franc/euro/pound/etc.}! Here are some links to get started:
