Evohome in Dashticz

[Scotty]

Hey.

So I'm up and running with Dashticz and I am absolutely loving it, bar one issue which will only affect Honeywell Evohome users.

Essentially, every Evohome device is only showing up in a 'Heating' block rather than a thermostat block meaning that I can't change the set-points and it just displays the temperature (I can change the setpoint in Domoticz but not Dashticz)

I've found the device handling function in the main.js which handles the blocks that are shown.

Code: Select all

	case 'Heating':
        case 'Radiator 1':
            return getTempHumBarBlock(device, idx);
        case 'Thermostat':
            return getThermostatBlock(device, idx);

I played around and got the thermostat style blocks to show but the data wasn't there and obviously the setpoint buttons don't work.

As an idea of the data available, here's the JSON for one of the zones:

Code: Select all

      {
         "AddjMulti" : 1.0,
         "AddjMulti2" : 1.0,
         "AddjValue" : 0.0,
         "AddjValue2" : 0.0,
         "BatteryLevel" : 255,
         "CustomImage" : 0,
         "Data" : "22.0 C, (5.0 C), HeatingOff",
         "Description" : "",
         "Favorite" : 1,
         "HardwareID" : 2,
         "HardwareName" : "Evo",
         "HardwareType" : "Evohome via Web API",
         "HardwareTypeVal" : 75,
         "HaveTimeout" : false,
         "ID" : "1483203",
         "LastUpdate" : "2019-09-26 17:16:56",
         "Name" : "Master Bedroom",
         "Notifications" : "false",
         "PlanID" : "0",
         "PlanIDs" : [ 0 ],
         "Protected" : false,
         "SetPoint" : 5.0,
         "ShowNotifications" : true,
         "SignalLevel" : 10,
         "Status" : "HeatingOff",
         "SubType" : "Zone",
         "Temp" : 22.0,
         "Timers" : "false",
         "Type" : "Heating",
         "TypeImg" : "override_mini",
         "Unit" : 3,
         "Used" : 1,
         "XOffset" : "0",
         "YOffset" : "0",
         "idx" : "3"
      }

Any help or guidance on making this work would be fantastic!

[Scotty]

I'd also like to add that Dashticz won't recognise the evohome zones when using graphs either.

Can anybody help enable this functionality?

[bolderbast]

Man, I would also love this functionality! I see an issue was opened already at https://github.com/Dashticz/dashticz/issues/68 , but no response yet...

[wimmme]

Would love this too.

[clinkadink]

Man, I would also love this functionality! I see an issue was opened already at https://github.com/Dashticz/dashticz/issues/68 , but no response yet...

There has been some progress. I just tested the updated code and it seems promising. Each evohome block now has a plus/minus button to control the heating.

Further info here ... https://github.com/Dashticz/dashticz/is ... -569833150

[clinkadink]

Thanks to Lokonli, I managed to get my Evohome working nicely in Dashticz.



I am unsure what next, so I have added the updates to a forked branch on github. My changes are to:

https://github.com/clinkadink/dashticz/ ... js/main.js
https://github.com/clinkadink/dashticz/ ... ettings.js
https://github.com/clinkadink/dashticz/ ... eative.css

I have added these to my config.js:

Code: Select all

config['setpoint_min'] = '5';
config['setpoint_max'] = '40';
config['evohome_status'] = 'Auto';		
config['evohome_boost_zone'] = 60; 	// minutes
config['evohome_boost_hw'] = 15; 	// minutes

[Lokonli]

Thanks!
I'll merge the changes into beta later this week.

Sent from my SM-A320FL using Tapatalk

[Scotty]

Amazing work guys. Thank you so much for looking into this. I have tested and the functionality works!

As a further improvement, would it be possible for us to look into the following:

- Adding graph support for Evohome devices.
- This may be a bigger fix for the way thermostats are managed in general within Dashticz but is it possible to change the way the temperature change is managed? Currently if I press + or - on one of the devices I have to wait a second or two for the device to update before I can press a button again to continue adjusting. This could take some time for a user to adjust the temperature by a large amount, especially at 0.5 degree intervals.

So in theory I would like to be able to press the + or - button several times before the command is sent to Domoticz. Maybe once a button is pressed, JS checks to see if that button has been pressed again in the last second before actually actioning anything.

I hope the above makes sense to somebody!

Thanks again,

Scott.

[Scotty]

So after all of your hard work It has inspired me to try and find a better way for me to change the temperature on my Dash. I just can't get along with the plus and minus buttons, they're painful to use from a GUI point of view.

In my ideal world, the way I see this working is with a normal temperature block but click on it and a modal appears with a slider.

I've made a proof of concept so far however I'm no programming expert. Trying to integrate this solution into Dashticz seems impossibly hard for me.

So far I have created a static HTML page, with a slider, that is loaded in a button/iframe within dashticz. The slider works really well and successfully changes the temp through Domoticz.

Now I'd just love this slider implemented properly without me fudging together a load of iframes.

The slider looks like this currently:


The slider library can be found here: https://roundsliderui.com/

The slider makes it easy to make big changes to the temperature in far less steps than constantly pressing the plus and minus buttons.

This is my frankensteined code that is behind the slider:

Code: Select all

        $( document ).ready(function() {
			
			$("#slider").roundSlider({
				radius: 72,
				circleShape: "half-top",
			  	sliderType: "min-range",
				mouseScrollAction: true,
			  	value: 19,
				handleSize: "+5",
				min: 10,
				max: 50,
				lineCap: "round",
				change: function (args) {
							console.log(args.value);
							//$('#range').html(args.value);
							switchEvoZone(args.value);
					 }     
			});
			
		});
			
			
		function switchEvoZone(setpoint) {

			$.ajax({
				url: 'http://192.168.0.22:8080/json.htm?type=setused&idx=2&setpoint=' + setpoint + '&mode=TemporaryOverride&until=2020-01-22T15:07:00&mode=Auto&used=true&jsoncallback=?',
				type: 'GET',
				contentType: 'application/json',
				dataType: 'jsonp',
				success: function () {
					//sliding = false;
					//alldevices[idx].SetPoint=setpoint;
					//getEvohomeZoneBlock(alldevices[idx], idx);
				}
			});
		}

Does anybody think this project could have legs or is it just me that needs this kind of functionality?

[clinkadink]

1. Adding graph support for Evohome devices.
2. This may be a bigger fix for the way thermostats are managed in general within Dashticz but is it possible to change the way the temperature change is managed? Currently if I press + or - on one of the devices I have to wait a second or two for the device to update before I can press a button again to continue adjusting. This could take some time for a user to adjust the temperature by a large amount, especially at 0.5 degree intervals.
So in theory I would like to be able to press the + or - button several times before the command is sent to Domoticz. Maybe once a button is pressed, JS checks to see if that button has been pressed again in the last second before actually actioning anything.

Hi Scotty,

Responses below:

1. I updated the multigraph branch to allow graphs and multigraphs to report on Evohome devices. You can see it working with 3 Evohome radiator TRVs in one multigraph. Hopefully, it won't be long until this is merged into the beta branch.
https://www.domoticz.com/forum/viewtopi ... 60#p234308

2. I have seen this too. The behaviour you see now is JS firing the click event at each button press. Despite milliseconds, it can interupt the next button press, as is it has to wait for a callback because its asynchronous. This is amplified if you are a 'quicker button presser' I'll see what I can do.

Cheers.

[clinkadink]

Does anybody think this project could have legs or is it just me that needs this kind of functionality?

I think the amount of possibilities that Dashticz provides, is almost endless. Yes, it has legs. But probably not specifically for Evohome devices. It could be repurposed for many different devices; obvious heating, but ventilation, lighting too.

The Evohome block buttons are set to +/- 0.5c at present. I have no need to increase/decrease my temperature for any zone, by more than 1 or 2c at any given time. It sounds as if you are changing the temperature by a lot more than me.

It also depends on the user and the device they are using it on. I would imagine sliders, interactive dials, guages would be quite intuitive on mobile devices. But for me at least, they offer less precision than a button via the PC

[Scotty]

Hey Clickadink,

I'm so grateful for all the work you've put into this so far. Thank you once again.

I guess my requirement for a dial/slider comes form the fact that when I don't want a zone to be on, I have the set point to several degrees lower than I'd expect the room to be. This can sometimes be several degree's off the ambient temp so several clicks, followed by a short wait, are needed. The wait is the killer for me. Perhaps a solution like this could be used? https://stackoverflow.com/questions/359 ... s-clicking

I'd expect this slider solution to be a great option for all heating/thermostat blocks so I agree, not exclusive to Evohome. It just comes down to being able to integrate the slider library into Dashticz as my skillset is somewhat limited.

For now, I will stick my my temporary iframe solution to amend the temperature as needed. Ultimately I'd like to be able to hide my main Evohome controller in a cupboard somewhere and just use my Dashticz panel to control everything.

[clinkadink]

Thanks Scotty, I get it now. The code could be updated as suggested. But theres always more than one way to skin a cat Any update would need to consider both mouse and touch inputs. With mouse, its a doodle. You would only run the command on the 'mouse leave' event. So as soon as the mouse cursor moves outside of the button area, it would update the temp. Sadly, there is no 'leave' event for touch. I have an update pending for Evohome code, so I will try and get it in with that.

[Scotty]

Perfect, I'll look out for your updated code soon.

I'm actually getting somewhere now with my little home-brew solution. I like to tinker with stuff like this so it's been a lot of fun.

Without the code written by clickdalink, which i scavenged from main.js, I wouldn't have been able to figure out how to work this so I'm extremely grateful.

In terms of functionality, it's working perfect. Just the final aesthetics to sort now.



Essentially on my Dashticz server(pi) I have a file called slide.php that will allow an idx variable to be passed to it and load everything needed to control that zone.

Code: Select all

frames.idx1 = {refreshiframe:30000,height:400,frameurl:"http://192.168.0.22/slide.php?idx=1",width:12}

[clinkadink]

Looks great! Well done

Why the need for PHP though? The zone data has already passed from the server (Pi in your case) to your client (browser). It seems like you are not using that, but instead, passing the device ID (zone id) back to the server (Pi), pulling the data from your zone separately, and then returning back to the client (for the second time). Just an observation, but perhaps I have misunderstood the setup

From a production perspective, it would be possible to have a block setting, for example "Type" with the option of "block" or "dial". The script would then display the data using whichever "type" you have specified, i.e. block (what we see today) or dial (what you are suggesting).

[Lokonli]

Looks great! Well done

Why the need for PHP though? The zone data has already passed from the server (Pi in your case) to your client (browser). It seems like you are not using that, but instead, passing the device ID (zone id) back to the server (Pi), pulling the data from your zone separately, and then returning back to the client (for the second time). Just an observation, but perhaps I have misunderstood the setup

From a production perspective, it would be possible to have a block setting, for example "Type" with the option of "block" or "dial". The script would then display the data using whichever "type" you have specified, i.e. block (what we see today) or dial (what you are suggesting).

This is indeed the preferred direction I would say. As third type we could have a linear slider (like we have for dimmable lights)

[Scotty]

Why the need for PHP though? The zone data has already passed from the server (Pi in your case) to your client (browser). It seems like you are not using that, but instead, passing the device ID (zone id) back to the server (Pi), pulling the data from your zone separately, and then returning back to the client (for the second time). Just an observation, but perhaps I have misunderstood the setup

Hehe, as I've eluded to previously, I'm no expert in this field and have tinkered until I found a working solution. I'm sure if you seen his code I've thrown together right now, you'd be horrified!

I guess I tend to programme more in PHP than any other language so it was the first way I imagined it working. I can definitely see the pitfalls and inefficiencies in my way of doing this, but it's essentially my hacked together way of producing the desired results.

slide.php is a single page, independent of Dashticz, called for 4 times for each of my zones within 4 iframes. Without using PHP, is there a way for slide.php/.html to know which zone to get json information from? How can I pass that variable from the block setup in CONFIG.js to the framed pages?

Another inefficiency in my method is that I have to reload dependancies in my independent page such as jQuery and moment.js to handle everything.

I'm happy to supply the work that I've done so far if you'd like to integrate it in a better fashion at some point. This is just the only way I know how

[clinkadink]

Yours is not too different from what I did a couple of years ago (before I switched to Domoticz/Dashticz). I created a webpage to display all my smart home data, including Evohome. I created the following gauge for each of my 10 zones plus hot water. The orange section of the bezel served several puposes:

- It indicated the current temperature (based on a 0-40c dial)
- The colour changes depending on whether it is above/below setpoint
- It allowed rotation of the bezel to quickly set the temperature

The grey number is the setpoint and when there is demand (it is heating), the red led at the bottom came on. It is very lightweight html and styling, and plugin free.



Regarding your question about passing the device ID to your PHP page. No, as your block config is in the client (browser) and your PHP is on the server. Sending anything from client to server is done by passing the parameter via PHP - which is what you are doing now. Any other way would could be easily exploited. Hence my earlier recommendation to keep it in the client

[Scotty]

Lovely. That's a great looking dial.

The demand LED is a great idea. I couldn't see any values that show when a zone is calling for heat. Did you just 'if (temp<setpoint){led=on;}'?

[clinkadink]

Correct