Best choise for a controller

[dzjr]

Hello MySensors friends,

I plan to completely rebuild my controller, probably with a RaspberryPi 4, the current configuration crashes regularly, I have already set up a second controller to be able to read one of my MySensors gateways, that helped for a while, but now domoticz restarts every 1.5 days on average, I have installed "Monit" on the Pi to monitor the controller.

Now I was wondering if domoticz is the right choice for my situation, or if you might recommend a better choice?

My setup is:
2x MySensors Ethernet gateways (both RS485) where I collect sensor data and control dimmers. relays, valves etc.
option for a 3rd MySensors gateway (RF Gateway).
DMX Garden lighting control (via MySensors with its own Ethernet gateway)
Z-Wave for the smoke detectors in my house.
IKEA Tradfri gateway, possibly with a ConBee-II Zigbee stick instead of the IKEA Gateway.
P1 Smart energy meter (Dutch energy meter)
APC UPS (via USB)
RF Link (for 433mhz components)
Sonos control
Modbus readout (possibly I can read through Mysensors?)
Read out Luftdaten sensor (via Json)
Push notification via PushOver

I now use a Raspberry Pi 3 with Domoticz Beta, but prefer to run stable
And a Raspberry Pi 2 with Domoticz Stable where I read one of my MySensors gateway's.
But I prefer to use one controller.

I am curious about your experiences and tips.

thank you in advance
dzjr

[electrik]

@dzjr
I use node-red and it is really stable. Mysensors gateway is ESP32 based with MQTT.
In the past I had some stability issues, but these were caused by plugins of Node-red. Perhaps this is a cause for your stability problems also? I don't know Domoticz, but I do know it is used very frequently so should be stable. Also corrupt SD cards can cause stability issues

[dzjr]

@electrik Thank you for your comment,

I was already thinking that it might be a problem with the SD card, so I ordered a new one from a better webshop (Reichelt.de).
I also ordered a new RaspberryPi 4 4GB, and then build a new controller with domoticz on the Pi4.

[zboblamont]

@dzjr SD cards caused failures on a Pi3 here mainly down to frequent power outages, but since you run on a UPS, puzzled why you should get corruptions or have instabilities.
The SD market is awash with fakes unfortunately, a major headache for even established suppliers, bought two, both failed within months.
Perhaps you might consider shifting from SD to HDD or SSD?
I got greater stability in using HDD, and even after one power cut too many screwed Domoticz, managed to recover the database.
Since deploying a DC/DC UPS, zero problems.
Good luck...

[dzjr]

@zboblamont thank you for your response

To be honest, a "Fake" SD card is very possible, just think that the card I used came from Action Store, which is very well known in the Netherlands, and which is not known as the most expensive store ....

I have now ordered a new Sandisk Micro SD card, but I am definitely considering your option for an SSD.

I had seen the DC/DC (Meanwell) UPS before (in a post from you?), But I already bought the APC UPS, which can also be an advantage given that my entire network continues to run for about 30 minutes at a (rare) power failure.

[zboblamont]

@dzjr It was Sandisk I bought too, the reputable supplier was furious to discover fakes made it onto their inventory, after all they purchase in thousands of units. I suspect they are a lot more careful these days.
Infuriatingly local powercuts are common here, deadly to a Pi3 SD card, but what was curious on the ultimate failure with a portable HDD in place, was that the database could be recovered from the HDD, unsuccessful with the SD card. And yes, backups were still on my to-do list...
Your UPS was the reason I queried SD card corruption, but cannot see the connection between corruption and Domoticz restarts.
Thought initially on a commercial UPS, but ultimately it was the standby capacity which swung it on DC-DC conversion, easily standing an outage exceeding 12 hours, or can provide additional outputs up to 12v (router).
Have not yet delved into the mysteries of Node-Red or MQTT unlike @electrik, but it certainly appears to offer flexibility, and remain curious..
Good luck in any case.

[dzjr]

@zboblamont

Do you use the SSD / HDD instead of the SD card, or only as storage?
Did you use a separate USB drive or a Rasp-Pi SSD sheild like for example this one ?

For the Pi4 I read that it is not (yet) supported to boot from SSD, namely ...

What strikes me is that if domoticz has to process more measurement data that monit sees a problem sooner, or that Domoticz is fixed ....
it seems like a buffer is full or something like that.

And do you use a Meanwell ADD-155 series for the UPS Power supply?

[zboblamont]

@dzjr The microSD acts only to redirect the Pi3 boot to the HDD, hence it's effectively RO. It can be reverted to full SD boot using a backup card if needed, the Pi4 is likely no different.
HDD is a simple slim Seagate laptop type running off a single USB port on the Pi3, the modern versions are light with a plastic case.
No issues for the original Pi3 PSU, had two coupled at one point, so they're very efficient. No need of a shield, only something to hold the drive to the wall.

The Meanwell from memory is AD55, a dedicated UPS type charging a 7.2Ah 12v battery to which it reverts on power failure. Power out is via a high efficiency buck converter with integrated USB, so plenty of headroom.
At below 50 euro built, very pleased, only mains detection to sort out as this PSU came without a breakout panel on the back for that purpose.

[rejoe2]

@dzjr You may have a look at FHEM. At least all of your present hardware will be supported, and it's really a stable base that might run on any rasberry base (despite imo that's not a good choice for any HA solution, but that's different story).

[dzjr]

@zboblamont
Thank you for the information, i will look for a good SSD, that is not so difficult i think.

Also i will think of ordering a AD55 for powering the pi instead of the 5V 5A psu i use now.

[dzjr]

@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.

[NeverDie]

If you want stability, then for the price of a new Raspberry Pi 4 (or even less) you can buy yourself a combo motherboard + intel CPU. Then you can bypass SD cards altogether. Load it with Debian and you'll have practically the same user experience, except that it will run noticeably faster than a raspberry pi.

[NeverDie]

Or, better yet, $39 gets you a refurbished mini PC with everything but the operating system all neatly packaged and ready to plug in and turn on: https://www.ebay.com/itm/Zotac-ZBOX-BI319-Mini-PC-Celeron-2807U-1-5Ghz-Plus-2GB-RAM-500G-HD-HDMI-NO-OS/173925495203?hash=item287ec471a3:g:zI4AAOSwBPZc-WiS

i have one of these running Windows that I had purchased new a couple years ago, and it's a nice little box. Very quiet.

[dzjr]

@neverdie

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.

[zboblamont]

@dzjr Perhaps SSD has moved on in $ and reliability since last I looked, but don't dismiss HDD so lightly, they may be old gen technology but are cheap and WAY faster than anything you'll ever need..

[monte]

I myself never got any problems with SD cards in my Pi's, but to ensure none of such will happen I've bought high endurance microSD from Samsung that costs about 3 times the price of a normal microSD card of the same brand and speed. They are designed to withstand continuous write for a warranty period. They are often used for onboard cameras and other surveillance equipment.
As for controller I highly recommend Home Assistant. It seems to be the most developed and highly supported platform with the biggest community and the widest customizability. I still use Domoticz at home, but currently finishing install of a system based on Home Assistant at my friend's home. After I've looked deeper into HA I am going to migrate my own home automation to it too.
If you have any network storage at home I would suggest you set up rsync to backup your config daily. HA can be installed like a Docker image, and it keeps all your config and custom installed modules/scripts/themes/etc in one folder, so it can be easily backed up and/or migrated to another system if needed.
In the latest versions they added ability to make most of the configs within web UI, though configuring with config YAML files is pretty straight forward and almost every option you would need is described in a vast and well organized documentation.

[rejoe2]

@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).

[monte]

@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.

[dzjr]

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.

[Grubstake]

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!

[NeverDie]

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.

[dzjr]

@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.

[dzjr]

@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.

[NeverDie]

@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.

[monte]

@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]

@monte Good questions. I'm not sure. I just know that it has been common for people to run HomeSeer on a VM, and those that do seem happy with it.

[rejoe2]

@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).

[monte]

@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.

[rejoe2]

@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...

[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

[monte]

@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.

[rejoe2]

@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]

@monte

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]

@rejoe2 Thank you also for pointing out FHEM, if you don't look at it you know for sure that it won't work!

Perhaps I will use it again in the future

[monte]

@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.

[TRS-80]

@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! 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. 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. 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 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 ) 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:

https://www.armbian.com/

https://linux-sunxi.org/Buying_guide

https://www.fsf.org/resources/hw/single-board-computers

[NeverDie]

@TRS-80 Have you decided yet which platform you do like? And if so, what is it?

[TRS-80]

@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).

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]

@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 Github

I 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]

@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]

@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]

@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.

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. Anyway, have to get back to work now...

[NeverDie]

@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]

@monte Sorry for the late response, I was working on other HA integrations so I left MySensors for a while.

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]

@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?

[alowhum]

@dzjr I had a look at your list, and as I read through it I realised that the Mozilla WebThings Gateway really needs P1 support. So I created an addon for that.

It might make the Mozilla WebThings Gateway an option for you, although it doesn't support all the things you asked for (DMX, Modbus, APC USB).

It does have great usability, privacy friendly local voice control, and of course MySensors support.

[alowhum]

There are also some very cheap usb-stick size SSD's now. Now sure about the long term quality, but it's.. interesting.

This 64Gb one is 15 dollars including shipping

This 128Gb one is $20.

Finally, this Kingdian one seems very popular. It's $30, but is a bit faster.

[NeverDie]

@monte said in 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.

Yes, I think you're right.