@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.
I have a similar project: For my fathers boat, I want to use a Nextion as a central informations display. I will use a asr6501 as self containing gateway/controller, so maybe we can exchange experiences.
@mfalkvidd said in Best PC platform for running Esxi/Docker at home?:
@NeverDie ...You can also use the command line tool fstrim to manually discard unused data.
Looking into this, I think checking the "Discard" box on the "Hard Disk" tab of the "Create a Virtual Machine" dialog box inside ProxMox may automatically accomplish the same thing. Also the ProxMox dataset that the VM is saved on needs to be set to thin-client. So, those two things plus the ssd emulation that you mentioned, and of course automatic file compression like lz4 needs to be enabled. So, in total, four things need to be set correctly for it to work optimally.
Originally I was concerned that because, if using ZFS as the file system, ProxMox only allows storing a VM as a pre-allocated "raw" file (rather than as a qcow2 file as ProxMox would if ProMox were using a linux ext16 file system instead of ZFS) that the file would take up enormous space even if the raw file (i.e. the VM's virtual disk) is mostly empty. So, I did the experiment, and it turns out that is true if the ProxMox dataset isn't configured as "thin-client" or if automatic file compression isn't turned on, but fortunately the true size of the raw file does indeed shrink down if those two conditions are enabled.
So, having proved that to myself, I'll pass on the tip: I now create a VM's disk to be as large as I can imagine it would ever need to grow, and then I let the thin-client mechanism maintain the true size of the virtual disk to be only as large as what is actually necessary. This way I don't have to worry that I created too small a VM disk, or that the VM will later outgrow the disk size that was originally allocated for it.
Bug in MYScontroller.
When I edit the file firmware_config.csv and set a version number with a decimal the output in the debug is wrong.
This is my file:
Note that I have 2.1 as the version in 40, Sovrummet.
But when I load the repo in MYSController v is 65535:
2021-02-13 17:06:37 REPO FW "Blink" loaded. t=10, v=1, blocks=80, crc=0x46D4
2021-02-13 17:06:37 REPO FW "Tvattstugan-2" loaded. t=20, v=3, blocks=1488, crc=0x6D13
2021-02-13 17:06:37 REPO FW "Tvattstugan" loaded. t=30, v=2, blocks=960, crc=0xBB4F
2021-02-13 17:06:37 REPO FW "Sovrummet" loaded. t=40, v=65535, blocks=936, crc=0x6AB3
2021-02-13 17:06:37 REPO FW repository loaded. Items=4
And in the GUI the version is also 65535.
Actually there are two bugs.
If I add (sloppy I know) more empty lines at the end in the firmware_config.csv file I get this in the debug:
2021-02-13 17:13:35 REPO FW "Blink" loaded. t=10, v=1, blocks=80, crc=0x46D4
2021-02-13 17:13:35 REPO FW "Tvattstugan-2" loaded. t=20, v=3, blocks=1488, crc=0x6D13
2021-02-13 17:13:35 REPO FW "Tvattstugan" loaded. t=30, v=2, blocks=960, crc=0xBB4F
2021-02-13 17:13:35 REPO FW "Sovrummet" loaded. t=40, v=65535, blocks=936, crc=0x6AB3
2021-02-13 17:13:35 ERROR 2107-15-31 is not a valid date specification
Other than that, great piece of software. Thanks.
I have been using OpenHAB and MQTT for a number of years now.
The reason for using MQTT and not just a serial connection from the MySensors GW is partly the flexibility as many have stated previously here. Easy to test, using e.g. the mqtt.fx tool. If you want to know what is going on you simply connect to the MQTT stream and "snoop" on the messages.
Another reason is that I am running three geographical sites on one OH installation. OH is running on a NUC at my home. There is also an MQTT GW here. Two other My Sensors MQTT-GW are running remotely in two summer houses. The three GW connect over internet to a cloud-based MQTT broker and OH connects to the same broker. In that way I do not have to open any ports into my home network for access should I have had a local MQTT-broker at home.
great idea for that translation from homie to mysensors and back.
but I think it would be a better approach, if mysensors would have the ability to "speak" homie-convention in MQTT optionally (e.g. #MY_GATEWAY_MQTT_HOMIE)
that would eliminate the need of tweaking on an extra binding and let mysensors talk an IOT-standard