Figured it out. I had to send HVAC_FLOW_STATE to HA, in order for it to figure out that it was a "thermostat". Only problem is that it shows up with states "Auto" "Cool" "Heat" and "Off" in the dashboard, even though I only have the possibility to heat, or turn it off.

I have started digging into home assistant again. I've been using node-red for the last 7-8 years, for all my automations.

I have one mysensors node setup as a thermostat (HVAC) controlling my floor heating. I have it working in a node-red dashboard, but would like to have it in HA as well.

When I present the child as a S_HVAC type sensor, it is not shown in the entity overview of HA. Only the childs defined as S_TEMP, but those I can't change from HA.

So is there anyone that has a working thermostat example for mysensors in HA?

I deployed 5 sensebender nodes just after release in 2015, all with 2 AA batteries from ikea.1 died within a couple of years, because it was placed outdoors. But the rest kept going, and all have been going until this year. So 8 years of battery time on one set of batteries..

I think that is excellent battery life.. ;)

@Yoshu you could boot linux off a usb, and check there..

@Yoshu Does the same device work on another machine, running win10 / linux?

Unfortunately I do not have any hardware compatible with win11, so can't test myself.. But if I remember right it should turn up as a generic cdc device..

Is there any info in the windows device manager?

@TheoL said in Merry X-mas:

Hey all,

I wanna wish you all the best X-mas - I know it's a little but early - and I wish you all some awesome projects in 2022. I hope we can get a creative spirit in 2022 and create cool things together.

Merry x-mas, and (an early) happy new year to you too :)

@keithellis
They should be available here https://itead.cc/product/mysensors-micro/

@monte said in Best PC platform for running Esxi/Docker at home?:

@tbowmo I don't know your setup, but optimizing the code that serves frames to the detector can help more then you may think.

I'm using zoneminder, and zmeventserver for this.. All running in docker at the moment.. Haven't had the time for digging in to this machine learning, other than scratch the surface, and trying to apply prior work to my own setup..

@monte currently I'm at the order of 0.2fps, would be nice with a bit more throughput, as I'm planning for more cameras along the way. (currently I have 2 cameras running 24/7,but have 2 more that I just need to put up..)

@NeverDie i prefer to keep video footage local. Not saying that I need an rtx3080/3090. They're too pricey. Looking more towards 1050ti or the like. Should be enough, if I'm not going for coral tpu. Waiting for a friend to get hold on some tpus, and give his verdict.

I've been looking at building a new server myself.. Currently I have an old hp desktop machine with an I5 / 16Gb of ram, running as server.. Works fine (and it was cheap). But I want to play more with docker / kubernetes, and perhaps do some more machinelearning on zoneminder images, so could use a cpu with a bit more oompf.. Perhaps an nvidia gfx for the ML part..

Only problem is that I'm not ready to spend 1000$ or more on hardware, so I'll probably just wait for the prices to drop again..

(Currently I just run ubuntu server, and then docker on top of that.. No VMs or the like..)

Perhaps my definition about "controller", is a bit broad here.

What could be done, is to have a thin "controller", that receives MQTT from the existing gateway, hands out IDs if they are requested from a new node, and translate the message into homie compliant topics. That is all it has to do, should not care about the rest of the automation at all. Should also be able to translate back from homie compliant to mysensors.

This could be written in python, c#, javascript, rust etc. The benefit is that you have (relatively) easy editing of configurations at hands, without re-uploading sketches to your gateways / nodes, if you decide that node X should be named Y instead.

And I am in no way trying to treat anyone as a fool!

@Peter-Loeffler
I still see this as a "controller" part, as it's mqtt you are totally free to subscribe to the messages from the gateway, transform it to something else, and then publish that onto mqtt as well.

That's the way I would do it, as it's much easier to edit config files etc on a computer (rpi etc).

@Peter-Loeffler

My reaction was mainly towards the part of your statement "very snobbish and autocratic".

I haven't seen a response about paying someone to do a feature request (I've been away from the forum, so maybe I have missed something?).

You are absolutely free to create a PR for any feature requests. We might fight back a bit ;) but we need to have a good use case for the features that make it into the core of the project, otherwise we get the project filled with features that is only used by 1 or 2 persons..

@Peter-Loeffler

You still need to tell the gateway "This node is 'living-room' and it transmit 'some-odd-property'" This needs to be configured somewhere, that be the node itself (and transmitted over the air/wire), or the gateway (or a computer running some software).

The current iteration of mysensors let the gateway run on an UNO. So that is the lowest common part that the gateway firmware needs to be compatible with (at the moment), and that mcu is too small in supporting the above schemes. Let alone, have all in the different sensor types programmed as text strings.

It might be doable in some future version, that is only in the talks (We've had some brainstorming on v3 of the protocol a couple of times).

There are many examples where of the shelf equipment downstairs make the cut. Of course if you only want temperature, or door switches, then zigbee devices are easier to implement. But if you want specialized Sensors, for measuring depth of water in a well, automate an existing garage door, automated the chicken coop, etc. Then mysensors is there to the rescue. Because you can't find any of the shelf non cloud solutions for that.

Perhaps we are behaving like old farts in the core ;) , but it's not intentionally. As mentioned a lot of times, we are using our spare time for the project, but the spare time is limited..

@Peter-Loeffler

The mqtt / serial protocol adhere very closely to the OTA protocol, where we are using byte sized nodeIds. This keeps the overall transmission payload down, and limits the time needed for transmitting a sensor value, and also keeps the likelyhood of errors down (Larger payloads = larger chance of failure). And currently chosen radios have a limited payload length

If we should implement the homie-convention (see below for an example) we need to be able to tell the gateway that nodeId 10 is device123, and childSensorId 1 is myThermostat. Then the gateway needs to store that info somewhere in a lookup table, to be able to do the conversion on the fly, as it's not feasible to send that info over the air for each transmission.

Also, we support the use of the same sketch on multiple devices with the current nodeId assignment. IE when you have 10 temperature sensors that all use the same sketch. The nodes get a nodeId from the controller, that it stored in eeprom, and re-used. Even if you re-program the device.

Homie-convention examples:

  homie / device123 / $homie → 3.0
  homie / device123 / $name → My device
  homie / device123 / $state → ready
  homie / device123 / $nodes → mythermostat

  homie / device123 / mythermostat / $name → My thermostat
  homie / device123 / mythermostat / $properties → temperature

  homie / device123 / mythermostat / temperature → 22 
  homie / device123 / mythermostat / temperature / $name → Temperature
  homie / device123 / mythermostat / temperature / $unit → °C
  homie / device123 / mythermostat / temperature / $datatype → integer
  homie / device123 / mythermostat / temperature / $settable → true

@Peter-Loeffler

I'm not sure how to address your statement. But beeing one of the core group members myself, I feel that it's a bit harsh. We all have a life, and fulltime job, besides mysensors! This means that we can't spend every minute of our (spare) time on mysensors all the time. Some of us have scaled down on activities for a period, due to children, work, house renovations etc.

Maybe we (the core group) say no to some new features in the project, but that is because we are uncertain about the following support / bugfixing of that particular feature. Specially in the light of the above, with limited spare time for the projects.

For my part, I've had a couple of rough years, that took the steam out of my envolvement in a lot of projects, including MySensors. But I'm slowly re-emerging from the deep dark now. So I hope that I get more time to do new fun sensors / hardware again. But things take time, and do not want to rush things, that could send me back into the dark again.

I admit that I have been pretty silent the last couple of years on the forum. But daytime work have drained my energy reserves. I have however just picked up mysensors again, and started jumping into platform Io for arduino. And converted one of my old mysensors sketches.

I hope that I can return to the community again, still have some fun hardware projects planned, but also need to constrain myself, so I do not have to many projects at the same time, otherwise my energy is depleted completely ;)

/ Thomas