Closed michelcve closed 4 years ago
~I'm wondering if the check for singleSetPoint and multipleSetPoints should be reversed. I might be wrong, but the device has 2 'temperatureSetPoint' (Heating 1, Heating Econ) entries, and a 'multipleSetPoints' (mode) entry (just a guess, maybe it helps):~
Edit: That doesn't seem to do the trick. I removed the integration, made the changed, and added the integration again. But it's still wrong
Ugh, I'd give it a try if I only could find how to delete a single device from the integration :-(
A fix is already on the way (see other issue reports).
@marcelveldt okay thanks, can I link this to one specific item perhaps?
I just published version .15 to HACS, please have a test with that. As we're already implementing the code into core Hass it would be great to get some feedback if this issue is resolved.
WARNING: version .15 contained a change to the internal id matching so it is normal that you need to rename your entities/devices again.
Great, I will look into it right now, and let you know.
Is there an easier way to rename? I had to rename 50 entities one by one last time, and it seems like there will be even more now :-/
No, not at this stage. This component is still in heavy development so not production ready (use at your own risk is what I'm saying here).
Once in core Home Assistant we will take care of migrating etc. and not introduce these breaking changes.
@marcelveldt I'm happy to report that it is now working! Thanks for the effort!
If I may be so bold, this device also provides a few other settings. Notably the 'valve opening' setting (which I use to determine if the radiator is attempting to heat up the room). In the 'old' zwave plugin, I had to make a hack, based on grabbing the OZW logs, to get that value. Which now won't work anymore.
Would it be possible to expose this value as well?
This is what is currently available with ZWave MQTT 0.15 in HomeAssistant:
These are the settings I can see in the ZWave admin tool:
@marcelveldt Closed the item, because the original issue is resolved now (but I'm stil wondering whether is would be feasable to add the other properties, mainly valve opening :-)).
OK, great that it's resolved. I will take a quick look at that valve value later today or tomorrow. If it's a quick fix I can ad dit in otherwise I will leave this as feature request for after we have the main stuff added in Hass.
No, not at this stage. This component is still in heavy development so not production ready (use at your own risk is what I'm saying here).
Once in core Home Assistant we will take care of migrating etc. and not introduce these breaking changes.
@marcelveldt Yeah, I understand.
And perhaps I'm doing it wrong, I'm not sure. I tent to rename all entity id's, as I need those (correct me if I'm wrong) in the YAML files (can't refer to friendly names here right?).
My experience with Home Assistant so far is that you sometimes need to throw away an integration, and re-add it. To get rid of incorrectly imported devices and stuff.
With the 'old' zwave, I could at least bulk rename the entity ID's on a per device basis, using the node_id as reference (so I could create a script for that, and run it through the service call).
I hope there will be something like that in the future, when it's matured.
Or perhaps include the node_id in the generated name (now for multiple devices with the same name, entity Id's after the first one are postfixed with _1, _2, etc. But you never know if a re-import will assign them the same way). Then I could assign friendly names to the devices, and use the entity_id's as they are generated in my yaml files. Less descriptive, but always derived the same way.
Thanks for all the hard work, otherwise really happy so far with the new ZWave integration!
@marcelveldt I'm happy to report that it is now working! Thanks for the effort!
If I may be so bold, this device also provides a few other settings. Notably the 'valve opening' setting (which I use to determine if the radiator is attempting to heat up the room). In the 'old' zwave plugin, I had to make a hack, based on grabbing the OZW logs, to get that value. Which now won't work anymore.
Would it be possible to expose this value as well?
This is what is currently available with ZWave MQTT 0.15 in HomeAssistant:
These are the settings I can see in the ZWave admin tool:
I would also love to see the valve opening implemented. I turn off my boiler heating system completely when all valves report below 10% opening level and switch on again when they report >25%. I am currently using the zwave2mqtt plugin but would be happy to switch to the new core implementation:-) Thanks for your great work!!
@michelcve I've looked at your request of adding the Valve position as a sensor. I've inspected your MQTT dump and there is no information published about the Valve Position. Maybe this is a bug upstream (in OpenZWave daemon) of your dump is incomplete.
@GitGramm can you do me a favor and post your mqtt dump here please so I can have a look if the Valve Position value is present in your data ? If not, we'll have to submit an issue report upstream.
@marcelveldt Strange indeed.
I did locate it in the openzwave code here:
https://github.com/OpenZWave/open-zwave/blob/master/config/eurotronic/eur_spiritz.xml
Lines 48-50:
<CommandClass id="38">
<Value genre="user" index="0" label="Valve Opening" max="100" min="0" type="byte" units="%" value="0"/>
</CommandClass>
File was last changed june 2019. So I would expect it to be in openwave.
As a matter of fact, in the OpenZWave Admin I can see the value:
Can you resend the full mqtt dump file again? Maybe some part got lost somehow ? OZW Admin uses the same mqtt data so the data should be there somehow ;-)
Nevermind: OZW Admin connects directly (not by using mqtt) to the daemon so it's still possible that the value is missing in the mqtt and not in the admin app.
@marcelveldt I'm not sure what is up with the mqtt.dump but I only seem to get a few nodes, and only partially. However, the Valve opening seems to be in this time. So here it goes...
Got it, thanks. This will be fixed in the version that will be submitted to Hass core.
@marcelveldt Thanks for your help! Great to see this feature coming to Hass core!
Any idea to when/what version it wil probably be released in?
The Eurotronic Spirit is only partially supported at the moment. It's missing the 'mode' parameter, which is causing the UI component to fail.