Best choise for a controller
-
@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:
-
@NeverDie said in Best choise for a controller:
@TRS-80 Have you decided yet which platform you do like? And if so, what is it?
When I started shopping a few years ago, I followed the advice from linux-sunxi and Armbian and I purchased a Cubietruck, which at that time was the best device (IMO) for a network attached storage type of device, to also run some services on. And the advice was very good, as the platform has not only run absolutely flawless these last few years, but has also continued to see updates, etc., exactly as predicted. I am on a recent kernel, and have full normal Debian software repository available to me! Very nice!
Incidentally, I run all sorts of services on it, not only HA controller (openHAB, which is a big Java based thing), but also network file storage, private XMPP Instant Messaging server (Prosody) for our family, and even more recently, even an email(!) aggregator, collecting from several different platforms and email addresses. And I only started with Linux with this device a few years ago, and look how far I have come already. Yes there is an investment to learn it, but so much professional level software is available that it is mind-boggling to me. Next I will set up completely private and self-hosted VoIP/video between some houses of our family!
Anyway, sorry, back to topic...
Right now I am waiting for 64-bit ARM to mature/stabilize, devices based on RK3399 are exciting (in theory) but I am starting to wonder if they will ever get the bugs worked out. If not these, then something else later perhaps...
(I want to run ZFS which requires 64-bit)
In the meantime I got impatient, I needed a little more CPU grunt for some software motion detection of my IP cameras (using Motion) and so I pulled the trigger on a couple ODROID-XU4 which are still 32-bit but have tons of horsepower (if running a bit hot) and have dropped a lot in price lately (I only gave $50 each for these octo-CPU USB3 true gigabit ethernet monsters (!) ).
But it is very application specific. If I had to buy another "front end" type of device for example for the living room TV, I would nowadays probably purchase something AM90x based, as from my reading these blow RPi out of the water in HDMI output (I still have the RPi in the living room running Kodi, it was one of the first devices I purchased before I knew any better). :D
Also the market is evolving constantly (although sort of slowly). What I mean is, new devices come out all the time with what seem (on paper) to be amazing specifications. But if the Chinese manufacturer is not following GPL and/or working with the community (releasing docs, etc.) then their device will never be well and fully supported in Linux, which is what you are really looking for long-term and why for example I have had such a good experience with my Cubietruck...
It can, admittedly, be a lot to follow, but a TL;DR for starters would be to stick with Armbian "recommended / stable" devices meeting whatever specs suit your application and you will have a much better time... And then for more info, start incorporating the links I posted above into your reading (especially Armbian forum), because the situation is constantly evolving...
I actually started even supporting a few dollars/month to Armbian now for several months, because I think what they are doing is so important in this evolving market right now...
-
@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.@monte
Among other things, I use a modified old telephone node from @SuperKris , I use fixed powersupply and RS485 as a transport layer.The Sketch is to big to post here
I have put it on my GithubI see all the devices in the JSON file (also on the github),
I also have a display node where i use N2N communication and 8 switch childs for controlling relays, There are more child IDs in the Json file but they were still there to test the display with MYSController, so you can ignore it completely, i have to remove them in the sketch.
The 3rd sensornode i have on de workbench i send some MQ values, doorcontacts, a PIR status and i recieve two childs.
i also uploaded on github.
but i see all the node id's in de json file. -
@NeverDie said in Best choise for a controller:
@TRS-80 Have you decided yet which platform you do like? And if so, what is it?
When I started shopping a few years ago, I followed the advice from linux-sunxi and Armbian and I purchased a Cubietruck, which at that time was the best device (IMO) for a network attached storage type of device, to also run some services on. And the advice was very good, as the platform has not only run absolutely flawless these last few years, but has also continued to see updates, etc., exactly as predicted. I am on a recent kernel, and have full normal Debian software repository available to me! Very nice!
Incidentally, I run all sorts of services on it, not only HA controller (openHAB, which is a big Java based thing), but also network file storage, private XMPP Instant Messaging server (Prosody) for our family, and even more recently, even an email(!) aggregator, collecting from several different platforms and email addresses. And I only started with Linux with this device a few years ago, and look how far I have come already. Yes there is an investment to learn it, but so much professional level software is available that it is mind-boggling to me. Next I will set up completely private and self-hosted VoIP/video between some houses of our family!
Anyway, sorry, back to topic...
Right now I am waiting for 64-bit ARM to mature/stabilize, devices based on RK3399 are exciting (in theory) but I am starting to wonder if they will ever get the bugs worked out. If not these, then something else later perhaps...
(I want to run ZFS which requires 64-bit)
In the meantime I got impatient, I needed a little more CPU grunt for some software motion detection of my IP cameras (using Motion) and so I pulled the trigger on a couple ODROID-XU4 which are still 32-bit but have tons of horsepower (if running a bit hot) and have dropped a lot in price lately (I only gave $50 each for these octo-CPU USB3 true gigabit ethernet monsters (!) ).
But it is very application specific. If I had to buy another "front end" type of device for example for the living room TV, I would nowadays probably purchase something AM90x based, as from my reading these blow RPi out of the water in HDMI output (I still have the RPi in the living room running Kodi, it was one of the first devices I purchased before I knew any better). :D
Also the market is evolving constantly (although sort of slowly). What I mean is, new devices come out all the time with what seem (on paper) to be amazing specifications. But if the Chinese manufacturer is not following GPL and/or working with the community (releasing docs, etc.) then their device will never be well and fully supported in Linux, which is what you are really looking for long-term and why for example I have had such a good experience with my Cubietruck...
It can, admittedly, be a lot to follow, but a TL;DR for starters would be to stick with Armbian "recommended / stable" devices meeting whatever specs suit your application and you will have a much better time... And then for more info, start incorporating the links I posted above into your reading (especially Armbian forum), because the situation is constantly evolving...
I actually started even supporting a few dollars/month to Armbian now for several months, because I think what they are doing is so important in this evolving market right now...
@TRS-80 Which OS do you recommend for running ZFS? Ubuntu has it, but allegedly only at an alpha quality level acording to arsTechnica: https://arstechnica.com/information-technology/2019/10/a-detailed-look-at-ubuntus-new-experimental-zfs-installer/
I definitely want the ZFS capabilities. I've been waiting for years for BTRFS to carry those features into Linux, but now I'm not sure it ever will, especially anytime soon. On the one hand BTRFS has been a part of SUSE for a while, but on the other hand Red Hat has deprecated it. I'm not yet close enough to it to have any insight.
-
@monte
Among other things, I use a modified old telephone node from @SuperKris , I use fixed powersupply and RS485 as a transport layer.The Sketch is to big to post here
I have put it on my GithubI see all the devices in the JSON file (also on the github),
I also have a display node where i use N2N communication and 8 switch childs for controlling relays, There are more child IDs in the Json file but they were still there to test the display with MYSController, so you can ignore it completely, i have to remove them in the sketch.
The 3rd sensornode i have on de workbench i send some MQ values, doorcontacts, a PIR status and i recieve two childs.
i also uploaded on github.
but i see all the node id's in de json file.@dzjr don't worry about posting long sketches here, just use code block tag and it will format it automatically and shrink it to appropriate size.
Please tell me, does any node show in HA interface?
I see you sending initial state for only one child. You have to do this for every child on a node if you want them to show up in HA interface, because from HA perspective every child of a node is a separate device. So even though they are present on the same node, you should treat them separately. Does this make sense to you?
For so many sensors on one node I suggest you use "for loop" while sending initial state. -
@TRS-80 Which OS do you recommend for running ZFS? Ubuntu has it, but allegedly only at an alpha quality level acording to arsTechnica: https://arstechnica.com/information-technology/2019/10/a-detailed-look-at-ubuntus-new-experimental-zfs-installer/
I definitely want the ZFS capabilities. I've been waiting for years for BTRFS to carry those features into Linux, but now I'm not sure it ever will, especially anytime soon. On the one hand BTRFS has been a part of SUSE for a while, but on the other hand Red Hat has deprecated it. I'm not yet close enough to it to have any insight.
@NeverDie said in Best choise for a controller:
Which OS do you recommend for running ZFS?
I have done a fair amount of research into ZFS although that was a couple years ago. ZFS started out at Sun Microsystems a long long time ago, and was native on (Solaris maybe?) and then it was ported to / available on BSD for a long time. It is generally regarded as being stable and well supported on the BSDs since a long time now. But I am a GNU/Linux guy. ;) Ubuntu is of course based on Debian, but I dislike Ubuntu project for many reasons and consider it a meme operating system (IMHO why not just use Debian?).
Anyway, some years ago the ZFS on Linux project began, and as of a few years ago it seemed to me that project not only had much more professional type backing behind it (Lawrence Livermore National Laboratory, among others) but also seemed to be much more stable and reliable than BTRFS. Now I am much more of a "Free Software" than an "Open Source" guy, so I am rooting for BTRFS, but IMO you cannot screw around with something so important as file reliability, especially when the entire purpose of these improved filesystems is to be more reliable in the first place...
Anyway, those factors, plus doing a lot of research on ZFS (study it's history, and why it was created in the first place, and also it's architecture of doing away with several legacy layers left from old file systems and beginning with a fresh design from the ground up) and like me you may also conclude that ZFS is the horse to bet on going forward. And by now (a few years later) I would be willing to bet that it is getting fairly stable on Linux (at any rate there is clearly a lot of development going on).
Once/if you reach the same conclusion I have, the next step is choosing hardware. ZFS requires 64-bit (and also ECC is recommended, but first things first). Apparently this is much more important than "a lot of memory" which is actually somewhat of a misnomer as it is only required for de-duplication (or certain other features, may be mis-stating exactly which ones).
As 64-bit x86 is a non-starter for me (for many reasons as already stated above), I continue waiting for 64-bit to mature on ARM, so that I, a mere peasant, may also enjoy enterprise-grade file system reliability, at a low cost using commodity hardware, and without having to give up any freedom or security. :D
If you are interested in learning more about what will be required to set up ZFS, I can recommend the following links:
- http://open-zfs.org/wiki/Hardware - For general understanding, but also the link to Marc Bevand's blog post From 32 to 2 ports: Ideal SATA/SAS Controllers for ZFS & Linux MD RAID is excellent. And in general there is a wealth of information in that wiki, more than you could ever want or need to know about ZFS probably.
- Wikipedia ZFS article is actually quite long and detailed, and gives a decent overview of the history and licensing issues / controversy.
- There was one more really good entry level article that I read a long time ago, that laid out all the most important points in a very approachable way, but I just spent quite some time searching for it and still came up empty handed. I think that was back before I started taking notes on everything I do in Orgmode. :D Anyway, have to get back to work now...
-
@NeverDie said in Best choise for a controller:
Which OS do you recommend for running ZFS?
I have done a fair amount of research into ZFS although that was a couple years ago. ZFS started out at Sun Microsystems a long long time ago, and was native on (Solaris maybe?) and then it was ported to / available on BSD for a long time. It is generally regarded as being stable and well supported on the BSDs since a long time now. But I am a GNU/Linux guy. ;) Ubuntu is of course based on Debian, but I dislike Ubuntu project for many reasons and consider it a meme operating system (IMHO why not just use Debian?).
Anyway, some years ago the ZFS on Linux project began, and as of a few years ago it seemed to me that project not only had much more professional type backing behind it (Lawrence Livermore National Laboratory, among others) but also seemed to be much more stable and reliable than BTRFS. Now I am much more of a "Free Software" than an "Open Source" guy, so I am rooting for BTRFS, but IMO you cannot screw around with something so important as file reliability, especially when the entire purpose of these improved filesystems is to be more reliable in the first place...
Anyway, those factors, plus doing a lot of research on ZFS (study it's history, and why it was created in the first place, and also it's architecture of doing away with several legacy layers left from old file systems and beginning with a fresh design from the ground up) and like me you may also conclude that ZFS is the horse to bet on going forward. And by now (a few years later) I would be willing to bet that it is getting fairly stable on Linux (at any rate there is clearly a lot of development going on).
Once/if you reach the same conclusion I have, the next step is choosing hardware. ZFS requires 64-bit (and also ECC is recommended, but first things first). Apparently this is much more important than "a lot of memory" which is actually somewhat of a misnomer as it is only required for de-duplication (or certain other features, may be mis-stating exactly which ones).
As 64-bit x86 is a non-starter for me (for many reasons as already stated above), I continue waiting for 64-bit to mature on ARM, so that I, a mere peasant, may also enjoy enterprise-grade file system reliability, at a low cost using commodity hardware, and without having to give up any freedom or security. :D
If you are interested in learning more about what will be required to set up ZFS, I can recommend the following links:
- http://open-zfs.org/wiki/Hardware - For general understanding, but also the link to Marc Bevand's blog post From 32 to 2 ports: Ideal SATA/SAS Controllers for ZFS & Linux MD RAID is excellent. And in general there is a wealth of information in that wiki, more than you could ever want or need to know about ZFS probably.
- Wikipedia ZFS article is actually quite long and detailed, and gives a decent overview of the history and licensing issues / controversy.
- There was one more really good entry level article that I read a long time ago, that laid out all the most important points in a very approachable way, but I just spent quite some time searching for it and still came up empty handed. I think that was back before I started taking notes on everything I do in Orgmode. :D Anyway, have to get back to work now...
@TRS-80 said in Best choise for a controller:
It is generally regarded as being stable and well supported on the BSDs since a long time now. But I am a GNU/Linux guy. Ubuntu is of course based on Debian, but I dislike Ubuntu project for many reasons and consider it a meme operating system (IMHO why not just use Debian?).
Yes, I'm on the same page as you regarding all the points you mentioned in this passage. Otherwise, a few years ago I would have simply learned BSD and its implementation of ZFS.
I'm at a point where I'd rather not keep waiting indefinitely though.
Thanks for the links! I'll give those a read.
-
@dzjr don't worry about posting long sketches here, just use code block tag and it will format it automatically and shrink it to appropriate size.
Please tell me, does any node show in HA interface?
I see you sending initial state for only one child. You have to do this for every child on a node if you want them to show up in HA interface, because from HA perspective every child of a node is a separate device. So even though they are present on the same node, you should treat them separately. Does this make sense to you?
For so many sensors on one node I suggest you use "for loop" while sending initial state.@monte Sorry for the late response, I was working on other HA integrations so I left MySensors for a while. :relaxed:
But now I had a Domoticz jam for the third time, so it was a trigger to make the move with at least one gateway.
I did indeed see some values in HA, but, as you may have seen in the other post, I have been so cheeky to just modify the JSON file, and that works!
I will, however, adapt new sensor nodes to the format desired by HA.
By the way, I want to make you very happy with HA now, what a lot of integrations are possible!
And it looks even better than Domoticz! -
@NeverDie said in Best choise for a controller:
Which OS do you recommend for running ZFS?
I have done a fair amount of research into ZFS although that was a couple years ago. ZFS started out at Sun Microsystems a long long time ago, and was native on (Solaris maybe?) and then it was ported to / available on BSD for a long time. It is generally regarded as being stable and well supported on the BSDs since a long time now. But I am a GNU/Linux guy. ;) Ubuntu is of course based on Debian, but I dislike Ubuntu project for many reasons and consider it a meme operating system (IMHO why not just use Debian?).
Anyway, some years ago the ZFS on Linux project began, and as of a few years ago it seemed to me that project not only had much more professional type backing behind it (Lawrence Livermore National Laboratory, among others) but also seemed to be much more stable and reliable than BTRFS. Now I am much more of a "Free Software" than an "Open Source" guy, so I am rooting for BTRFS, but IMO you cannot screw around with something so important as file reliability, especially when the entire purpose of these improved filesystems is to be more reliable in the first place...
Anyway, those factors, plus doing a lot of research on ZFS (study it's history, and why it was created in the first place, and also it's architecture of doing away with several legacy layers left from old file systems and beginning with a fresh design from the ground up) and like me you may also conclude that ZFS is the horse to bet on going forward. And by now (a few years later) I would be willing to bet that it is getting fairly stable on Linux (at any rate there is clearly a lot of development going on).
Once/if you reach the same conclusion I have, the next step is choosing hardware. ZFS requires 64-bit (and also ECC is recommended, but first things first). Apparently this is much more important than "a lot of memory" which is actually somewhat of a misnomer as it is only required for de-duplication (or certain other features, may be mis-stating exactly which ones).
As 64-bit x86 is a non-starter for me (for many reasons as already stated above), I continue waiting for 64-bit to mature on ARM, so that I, a mere peasant, may also enjoy enterprise-grade file system reliability, at a low cost using commodity hardware, and without having to give up any freedom or security. :D
If you are interested in learning more about what will be required to set up ZFS, I can recommend the following links:
- http://open-zfs.org/wiki/Hardware - For general understanding, but also the link to Marc Bevand's blog post From 32 to 2 ports: Ideal SATA/SAS Controllers for ZFS & Linux MD RAID is excellent. And in general there is a wealth of information in that wiki, more than you could ever want or need to know about ZFS probably.
- Wikipedia ZFS article is actually quite long and detailed, and gives a decent overview of the history and licensing issues / controversy.
- There was one more really good entry level article that I read a long time ago, that laid out all the most important points in a very approachable way, but I just spent quite some time searching for it and still came up empty handed. I think that was back before I started taking notes on everything I do in Orgmode. :D Anyway, have to get back to work now...
@TRS-80
I think I'm finally sold on BTRFS: https://markmcb.com/2020/01/07/five-years-of-btrfs/Did you opt to go with ZFS on Linux?
