It is not exposed as a sensor attribute but you can download the diagnostics and look for ‘BoilerSettings’ where you can see it. This diagnostics data updates with each poll of the hub.
1 Like
Thanks Mark, found it:
"BoilerSettings": {
"ControlType": "HeatSourceType_RelayControlled",
"FuelType": "Oil",
"CycleRate": "CPH_3",
"OnOffHysteresis": 5
},
Is anyone else having a problem with saving after editing a schedule?
I’ve been trying to modify my hot water schedule. I make changes, press Save and it just sits there spinning without saving. There’s nothing obvious in the logs.
1 Like
I suspect your HeatHub was offline.
When this happens to me with both the wiser integration and the Wiser app then I go look at the HeatHub and hey I have a red light!
Thanks for the update Jamie,
I too look forward to this firmware upgrade.
For info:
I have an open ticket #147821 with yourselves (Wiser Drayton) regarding this issue but your support colleagues keep ignoring my frequent referrals to your posts on this forum and also posts on the Wiser forum.
They do not acknowledge that there is an open issue that you are working on.
Now after giving them all the details they require, they have “done some tests” on my installation and found my HeatHub is connected to both Wi|Fi and the cloud.
Well yes it was when they did their tests.
I have offered to provide graphs and details of periods of discons over any time span they require but (as the Americans say) “Crickets”
Now they are telling me that the HeatHub should be installed no closer than 1 “meter” from the boiler because of “attenuation with the boiler”.
Well mine is and always has been.
Maybe you could point me to where it says this in your installation instructions bearing in mind my Wiser system has been installed for over 5 years and at least 4 years with the HA wiser integration without this issue manifesting itself until the last couple of months. I acknowledge the HeatHub did drop off occasionally but not like it does now. Is this to do with a previous firmware update maybe?
Mike
Unfortunately not the case. The hub is online and the Wiser app is working.
I’ve tried restarting HA but no change.
Support won’t acknowledge that there is an open issue and they would be right, there is no ‘bug’ here as the WiFi handling and stack haven’t changed for some time. The new firmware version will enhance the WiFi handling for installations with low WiFi signal/range and Mesh Networks, it will also help when the WiFi connection drops for any reason (conflicts, interruptions, Mesh healing, etc). Finally, we have added a lot more logging around the WiFi handling to help diagnose individual customer problems in the future.
4 Likes
Thanks Jamie,
Good to know.
I have a wiser basic hub in China. When I follow the instruction to get the secret key, my phone will connect to the wifi Wiserxx_xxxxxx and acquire ip 192.168.220.*. And then I try to go to http://192.168.8.1/secret or http://192.168.220.1/secret, but it is not working. I also try to use Httpcanary app to capture the Wiser packet. When Httpcanary start to capture packet, Wiser will be offline and no packet will be captured. I really don’t know how to get secret key.
MQTT integration of iTRV is absolutely broken even though it is listed as working
Setting actually still works in the app, app just don’t show what is currently selected. I’ve set my heating type to oil and boiler can only fire up to 3 times per hour now.
Confirmed on official forum https://community.se.com/t5/Schneider-Electric-Wiser-Forum/Heat-Source-Type-is-not-saving-in-APP/m-p/418651#M364
@Chaoscontrol @Scoff this answers your question as well
Still couldn’t get it to work, so I modified the schedule in the Wiser App, which updated it on HA fine.
No clearer as to why it wouldn’t save from HA but at least I’ve changed the schedule.
You may be getting an error in your browser console. Check here and let me know what you find. Not seeing any issues but maybe an unknown scenario causing a problem.
Hi Mark,
I get the following error in the browser console:
Since it reports as ‘Unknown error’ not sure if it’s of any use?
Are you running v3.2.3beta or v3.2.3beta2? There was an error in v3.2.3beta which maybe the cause of this which is fixed in v3.2.3beta2.
A climate entity , with heating actuators , provides :
heating_type: ElectricRadiator
number_of_heating_actuators: 1
demand_type: Modulating
heating_rate: 2984
percentage_demand: 0
comfort_mode_score: 21339
…
My understanding of the heating_rate and comfort_mode_score are representing quality or performance of the system, how are they built? what interpretation can we make?
Demand_type : modulating is there other demand type? The output signal work like a PWM, then what is the period.
1 Like
I’m running beta2.
Do wiser TRVs ever open the valve fully? I’ve run some experiments using a wiser TRV, a normal manual TRV and a few valves (including Drayton valves). These experiments were run with the valves not connected to any pipes, just on a table.
In all cases I’ve reset and recalibrated the iTRV before each test.
The result was that when the iTRV is at 100% demand (by setting the setpoint to 30C while the temp is 19) what happens is that the valve pin is only retracted 1-2mm instead of more than 4mm.
A normal manual TRV, when set to the highest setting causes the valve pin to retract 4mm (fully open).
It is interesting that during calibration after reset the iTRV motor does get fully up (pin fully retracted ) but at normal operation and 100% demand the pin opens much less.
Why would this happen, seems to be by design. I’m wondering if this is intentional or a bug. It surely must affect how fast the rad heats up at full demand.
Here’s some pictures of a Drayton valve with iTRV and manual TRV when ‘fully retracted’
On calibration: my understanding is that during calibration the motor extends as far as possible until it finds resistance (fulkyc closed) so it learns that eg 7mm extension are needed for fully closed.
What I am figuring out now is that it doesn’t really know where the fully open position is.
So what it does instead of retracting full when it needs to open fully is to retract just by 2mm from the fully closed position at most.
3 Likes
Hi,
That’s really interesting.
After calibration or battery replacement, some of my iTRV’s on a different valve body to the majority of my rads, I have found that when the demand is high the rad never heats up ( the valve doesn’t open properly).
To solve this I have had to back off the iTRV a few mms by unscrewing it a turn or two from the valve body.
This obviously makes the valve open. The other interesting thing is when the demand for that room is zero the rad is cool even though other rooms are still calling for heat and getting it, so the valve is closed.
So my experience backs up your claim, the iTRV is not moving the pin back far enough.
1 Like
@Duke_box I don’t think unscrewing a turn or two fixes this unfortunately. By doing that after calibration you’ll end up with the valve opening a bit more when fully open but the valve won’t close fully when fully off, as it’d still remember that it needs to extend e.g. 7mm for full close but now it’d need a bit more. So you’ll end up with a valve that let’s some heat in when wiser thinks it’s fully closed.
Now if you recalibrate after unscrewing two turns you’ll end up at the same odd place: the valve will fully close (by extending a bit more say 8mm) but again won’t open more than originally.
This is because it seems that the iTRV is configured to be fully open when 2mm retracted from the calibrated fully closed position and no more. It’s really weird it works like this.
I’ve also seen that the iTRV actually modulates the pin: it’s not always fully on or fully off, it tries to behave as a modulating TRV as well depending on the demand percentage of the room.
2 Likes