Hi @edoardoo
I actually stumbled on your post a couple of weeks ago! Great writeup!
We certainly need contributors. We need help with everything from the visualisation of sensordata in the frontend (considering using d3.js) to mqtt/node.js backend for receiving and processing sensor data.
Please contact me or Johan for further discussions.
Hi dzairo,
Just wondering if you still monitor this thread. If so would love to know how to install the ComPort component so I can modify and use your terminal code. For some reason I don't have any luck with adding it to the IDE.
thanks, Andy.
@OldSurferDude use a host name for the broker in the configure command (--my-controller-url-address=). Add the host name to /etc/hosts on the rpi where the gateway is. Start the MySensors gatway.
When you want to switch brokers, modify /etc/hosts again and restart the MySensors gateway.
@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.
