Controllers

@JanJaap-Jagtenberg according to https://www.reddit.com/r/tradfri/s/gvFcOmHe8h the ”best” solution is to replace the led driver (but keep the lights). An alternative might be to buy a used remote on ebay or a local equivalent. Do you know what is wrong with your current remote? Maybe it can be fixed?

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.

@Feliw05 Selecting the "right" controller is of course a matter of opinion and depends how far you want to go into the homeautomation swamp ;) . Normally i don't give advice like this (and i agree with @mfalkvidd - It's great to discuss with a friend!) but here a my 2 cents... I think i've tried them all in the table but i always return to 2 alternatives: homeassistant and domoticz. If you want the fastest way to get started with good trend charts i still think Domoticz is a great choise. The UI is not the prettiest (even if you can fix that by setting up custom dashboards like dashticz or so) but it's very functional and i think it has a good default setup with trendlines per sensor for day/month/year using highcharts. I have a few weather station systems running remote and then i use domoticz in docker containers on off site servers (but i've also had it running on rasberry PIs). Very light weight. [image: 1645380519477-ec6576da-d173-4cf3-b72b-db0aab14717e-image.png] Another alternative (maybe obvious) is homeassistant but it might be a bit overwelming since it's very flexible and can be run in so many different ways so you will find tons of howtos that doesn't work anymore. It has a very active community that isn't afraid of changing core concepts when needed which is both a strength and sometimes a weakness. For my personal homeautomation i have moved over completely to homeassistant and it's possible to create beautiful dashboards with little effort. Is has integrations for more or less everything and if not there will be soon or you can add it yourself. Example dashboard that i have in the house with car heating/charging, cameras and tons of sensors and zigbee devices. Actually used and appretiated by everyone in the house :dart: [image: 1645380409836-081afea4-49ce-409f-965d-9950f828aad8-image-resized.png] It's a bumpier ride at least at first but i think homeassistant wins in the long run - and it's open source!

Hi @Prohi, can you provide more information about your heating system? When searching about AirMax on the internet, I found this: https://www.airmaxhvac.com/ and this https://airmaxsc.com/ and this https://airmaxop.com/ and ... Is your heating system an hvac based system? With remote controls for each room?

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

@David-Dawson 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

Naturally, using Tasmota instead of ESPHome should work equally well.

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

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

@hj_sk - yes, I always set ID in each node.

@hek thanks! It took us way more than expected to re-architect all the thing but now that is ready, happy with the result so your positive feedback is appreciated :-) Legacy myHouse issue was mainly around extensibility hence this distributed, plugin-based architecture allowing users to package functionalities and/or contents without me doing any change in the core code. And turning it in a cloud-based service (as an option) could be also really easy. But for now the hope is to build a little community around it so to make it evolve further. Just as a starting point :-)

I just buy them in brick and mortar store. Always genuine.

Same here. It's easy. I use it mostly for the battery status. It's the only red value on my mirror, at least, when they're almost drained.

There doesn't seem to be a ton of interest in this but I wanted to provide an update. After writing the transport and using it for a bit I've decided to go another direction with the integration to SmartThings. I felt like the custom transport would require more maintenance and I wanted more of any option that was configuration rather than coding. Because there was C++ code on the MySensors side of things and then Groovy on the SmartThings side it just seemed like a brittle integration with the design and how I wrote the code. SmartThings is going to be moving in another development platform direction as well at some point. I'm working on an MQTT solution with Mosquitto and Node Red (on a Raspberry Pi) and it will also require some Groovy on SmartThings but a much simpler solution IMO. There will be more to come and I'll share here when it's complete but I do have a prototype/proof of concept working. The two way communication is much better/cleaner IMO than how I did it with the transport. If this is something that interests you let me know and I'd be happy to collaborate.

@phil2020 Thanks for reporting back. Do you happen to have a full debug log of both nodes incl. GW debug log while assigning ID 255, rebooting and setting new IDs (without random delay) - I'd like to understand why the random token verification failed.