dashticz: Important Request

[edge]

Grrrr can't get access-control-allow-origin header working with nginx. Anyone who can help me with that one?

[Lokonli]

Wow had to read back a lot and good to see that most off you already have it working again!!

Nope, i cant get it to work.
I started from scratch, installed dashticz in var/www/html (instead of domoticz/www) with all the necessary dependencies.
I also tried to host the files on my synology and redirected to that address but still no luck.

Can someone make a clear tutorial how to change this.

And one question, if i change the icall/garbage file wont this be a problem with the next git pull update?

See my post 2 up... For me it work now. Only the custom icons part is gone now. But rest is working

The fontawesome update some time ago results in different names for the icons to be used.
The new name for fa-window-close is:
'far fa-window-close' for a regular icon.
or
'fas fa-window-close' for a solid icon.

On fontawesome.com you can find the correct names. Sometimes only fas or far is supported (not both). Sometimes there is a small change in the name as well.

[poudenes]

Nope, i cant get it to work.
I started from scratch, installed dashticz in var/www/html (instead of domoticz/www) with all the necessary dependencies.
I also tried to host the files on my synology and redirected to that address but still no luck.

Can someone make a clear tutorial how to change this.

And one question, if i change the icall/garbage file wont this be a problem with the next git pull update?

See my post 2 up... For me it work now. Only the custom icons part is gone now. But rest is working

The fontawesome update some time ago results in different names for the icons to be used.
The new name for fa-window-close is:
'far fa-window-close' for a regular icon.
or
'fas fa-window-close' for a solid icon.

On fontawesome.com you can find the correct names. Sometimes only fas or far is supported (not both). Sometimes there is a small change in the name as well.

I will check it. As far as I could see this morning some where same. But will look again. Thanks!


Verzonden vanaf mijn iPhone met Tapatalk Pro

[EastXIII]

Grrrr can't get access-control-allow-origin header working with nginx. Anyone who can help me with that one?

Same here. Man I need to learn a lot...

[gielie]

Wow had to read back a lot and good to see that most off you already have it working again!!

Nope, i cant get it to work.
I started from scratch, installed dashticz in var/www/html (instead of domoticz/www) with all the necessary dependencies.
I also tried to host the files on my synology and redirected to that address but still no luck.

Can someone make a clear tutorial how to change this.

And one question, if i change the icall/garbage file wont this be a problem with the next git pull update?

See my post 2 up... For me it work now. Only the custom icons part is gone now. But rest is working

That is only the apache/server part and i'm sure this is working fine because i run other web applications using apache.
im sure It is the dashticz part that need a change which i cant get right.

[stuffer]

Wow had to read back a lot and good to see that most off you already have it working again!!

@robgeerts

Almost

First I want to thank you for the project. A crate of beer is on his way when I get this working (or at the Jumbo 1,5 for the price for one )

What I did on my Ubuntu 16 machine for domoticz:

apt install apache2
apt-get install python-software-properties
add-apt-repository ppa:ondrej/php
apt-get update
apt-get install php7.2
apt-get install php7.2-curl
service apache2 restart
nano /home/pi/domoticz/www/dashboard/js/calendar.js

//\\changed://\\

if (settings['calendar_parse_localy']){
curUrl = './vendor/dashticz/ical/?time=' + cache + '&url=' + curUrl;
} else {
curUrl = 'https://dashticz.nl/ical/?time=' + cache + '&url=' + curUrl;
}

//\\to//\\

change curUrl = 'https://MYOWNDOMOTICZIP/ical/?time=' + cache + '&url=' + curUrl;

and add this in my CONFIG.js
config['calendar_parse_localy']=true;

With the result that the dutch tv section is working again. Only my 2 iCals are still not responding. (Google and RMN https://inzamelschema.rmn.nl/ical/0356200000014977)

What is the best way to look at this?

The CONFIG.js setting should be:
config['calendar_parse_localy']=1;

The change you made in calendar.js is not needed (and incorrect) so better to revert that one.

Ok, I reverted the calendar.js and changed: config['calendar_parse_localy']=true; --> config['calendar_parse_localy']=1;

Still no luck. Where i can start to debug this? It feels that i am pretty close but I don't no where to start searching.
(and I hope to create an how to for other users)

[Lokonli]

Ok, I reverted the calendar.js and changed: config['calendar_parse_localy']=true; --> config['calendar_parse_localy']=1;

Still no luck. Where i can start to debug this? It feels that i am pretty close but I don't no where to start searching.
(and I hope to create an how to for other users)

For the debugging: press F12 in Chrome, and look for errors in the console.

[poudenes]

Nope, i cant get it to work.
I started from scratch, installed dashticz in var/www/html (instead of domoticz/www) with all the necessary dependencies.
I also tried to host the files on my synology and redirected to that address but still no luck.

Can someone make a clear tutorial how to change this.

And one question, if i change the icall/garbage file wont this be a problem with the next git pull update?

See my post 2 up... For me it work now. Only the custom icons part is gone now. But rest is working

That is only the apache/server part and i'm sure this is working fine because i run other web applications using apache.
im sure It is the dashticz part that need a change which i cant get right.

I didn't change anything inside the Dashticz code. Only add

Code: Select all

config['calendar_parse_localy']=true; 

to CONFIG.js

[gielie]

See my post 2 up... For me it work now. Only the custom icons part is gone now. But rest is working

That is only the apache/server part and i'm sure this is working fine because i run other web applications using apache.
im sure It is the dashticz part that need a change which i cant get right.

I didn't change anything inside the Dashticz code. Only add

Code: Select all

config['calendar_parse_localy']=true; 

to CONFIG.js

And that doesn’t make sense because it should be 1 or 0 instead of false/true.
But again am sure my server side is working fine, it’s the dashticz part I can’t figure out why it’s not working.
Looking at all the answers and solutions here there is more then 1 so if someone could update the wiki so everybody can get it to work again cause if I don’t fix this my wife’s gonna pull of the tablet off the wall and make me place back the normals thermostat back.

[poudenes]

Only problem i still have is the Weather icons. Load very very slow in latest Dasthicz version.

[jake]

Only problem i still have is the Weather icons. Load very very slow in latest Dasthicz version.

Yes, I experience the same. It would be nice if the weather part did not have to reload every time. How much does weather change in forecast? Not too much.
I wonder actually what the default 5 minute reload is good for? Will the calendar not update without that? In that case it would be awesome if only that block is reloaded.

[gielie]

Only problem i still have is the Weather icons. Load very very slow in latest Dasthicz version.

Same problem, very very slow, not workable

[Lokonli]

Only problem i still have is the Weather icons. Load very very slow in latest Dasthicz version.

Same problem, very very slow, not workable

I cannot reproduce the problem. Which weather provider are you using? WU or OWM? In case of WU, try with OWM. WU is using cors-anywhere.herokuapp.com, which might introduce some delay.

You cannot use WU and OWM simultaneously.

In CONFIG.js add:

Code: Select all

config['owm_api'] = 'your OpenWeatherMap key';
config['owm_city'] = 'Mainaschaff';
config['owm_name'] = '';
config['owm_country'] = 'de';

then replace in your block 'weather' with 'weather_owm' and 'currentweather_big' with ' currentweather_big_owm'

[EdwinK]

No problems with OWM.

[Derik]

Is there perhaps someone that have a simple how to ...
To install all the nice stuf from rob on my RPi, r my Slave rpi..
I see servel solutions..
Only a simple one..

Thanks!!

[jake]

I cannot reproduce the problem. Which weather provider are you using? WU or OWM? In case of WU, try with OWM. WU is using cors-anywhere.herokuapp.com, which might introduce some delay.

You cannot use WU and OWM simultaneously.

In CONFIG.js add:

Code: Select all

config['owm_api'] = 'your OpenWeatherMap key';
config['owm_city'] = 'Mainaschaff';
config['owm_name'] = '';
config['owm_country'] = 'de';

then replace in your block 'weather' with 'weather_owm' and 'currentweather_big' with ' currentweather_big_owm'

This makes sense. When the icons won't load and I have the browser in debugging mode, I see the following error:

Code: Select all

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource
at https://cors-anywhere.herokuapp.com/https://api.wunderground.com/api/1xxxxxxxxxxxxxxxxxd/forecast10day/q/NL/Dxxxxxxx.json. 
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]

I once tried the OWM, but the layout is completely different, it shows a different type of forecast, I believe for the next coming 5x 3 hours or something like that? I like the 4 daily forecast from WU. However, we know that they will cancel their service as of beginning of 2019.

btw, a similar error shows up sometimes for the 'longfonds' block, it also has to do with the 'https://cors-anywhere.herokuapp.com'

[jake]

HVC is part of 'afvalstromen'. For afvalstromen all code already is implemented, except for HVC. I'll make the fix this weekend.

Thanks for fixing. I was happy to see the dates with their respective colors back. However, when I looked at the type of garbage being picked up next (Restafval: maandag), I realized that it is not correct. This was last Monday and not next Monday. Next Monday it will be GFT instead. Number 2 and 3 on my list (I limited it to 3) are correct for next week Thursday, (Papier and Plastic).
29-10-18: Code is updated by Lokonli and HVC works now as expected!

I updated the Dashticz wiki page with the new situation for the Module - Garbage collector. Please check my changes. I also put some comments in the Module - Calendar. I wonder if we still yes/no need the config.js parameter: config['calendar_parse_localy']=true;
Please also check / modify / add that section as well.

[b00n]

Grrrr can't get access-control-allow-origin header working with nginx. Anyone who can help me with that one?

Same here. Man I need to learn a lot...

Try this:

The easy way is to just add the extension in google chrome to allow access using CORS.

(https://chrome.google.com/webstore/deta ... ihlkkiljbi...)

Just enable this extension whenever you want allow access to no 'access-control-allow-origin'header request.

[Freekers]

Are you still looking for webhosting? If so, what specs are you looking for? I might be able to help you out depending on your requirements.

[Lokonli]

HVC is part of 'afvalstromen'. For afvalstromen all code already is implemented, except for HVC. I'll make the fix this weekend.

Thanks for fixing. I was happy to see the dates with their respective colors back. However, when I looked at the type of garbage being picked up next (Restafval: maandag), I realized that it is not correct. This was last Monday and not next Monday. Next Monday it will be GFT instead. Number 2 and 3 on my list (I limited it to 3) are correct for next week Thursday, (Papier and Plastic).

I updated the Dashticz wiki page with the new situation for the Module - Garbage collector. Please check my changes. I also put some comments in the Module - Calendar. I wonder if we still yes/no need the config.js parameter: config['calendar_parse_localy']=true;
Please also check / modify / add that section as well.

Thanks for updating the wiki! I've added a few garbage companies that are supported as well already.

The calendar_parse_localy setting is indeed not needed/not used anymore.