Hey, @Goldjunge_Chriz
I need two glasses, but they are each much smaller than 0.4 sqm.
Do I need to pay the price for 0.4 each or will both parts be totalized to one price?

This is what I need:

0.545x0.32 // 0.174 // Treuenbrietzen, Brandenburg // polished edges // delivery
0.63x0.365 // 0.23 // Treuenbrietzen, Brandenburg // polished edges // delivery

Both glasses together totalize to 0.404 sqm, so could it maybe totalized to one price?

If it’s possible you can put both glasses into one delivery package.

Thanks in advace!
Greetings!

P.S.: Thanks by the way, for this awesome possibility provided by you! I really appreciate that!

Okay, I think there’s a misunderstanding here.

To make things clear for the future:
The Module from @olexs MMM-PublicTransportDB is not really the same as my MMM-PublicTransportBerlin. Olexs made some changes on the original module to use the data from DB (Deutsche Bahn) while my module is just using the data from VBB (Verkehrsverbund Berlin-Brandenburg).

I think this could be the reason why the stationIds you used did not work @Jay. Since you used a stationId from VBB for DB data. I didn’t test this but maybe @olexs can make a statement to this?

Hey @Jay,
what did you have to change for the module name in the config?! o_O
I didn’t make any changes according this…

You can get valid station IDs via an easy cURL command as mentioned in the readme like this (you can do it from the mirror’s command line):

curl 'https://transport.rest/stations?query=alexanderplatz'

You just have to switch ‘alexanderplatz’ with your nearest station. This command will return all station fitting the search term.

@Advokaten
The data will be transferred, since vdirsyncer synchronizes the whole calendar data (including description, location, time, title,…). So all the calendar data you enter in your iCloud account will be synchronized to your mirror.

What you are asking depends heavily on the calendar module you are using on your mirror. I don’t think, that the default module supports this. So I think one needs to change stuff in the calendar module for this to work.

So I think what you’re asking is not really related to the syncing itself. If you’re already using the default calendar module, you already know how it looks. I didn’t change a single thing on that regarding optics. So the look is 100% similar to the default calendar module.

@Photon2000 Yeah, the problem is, that midori doesn’t support ECMAScript 6 (ES6) features. But the module is using some of them.

Unfortunately I don’t have much time in the near future to convert the module to vanilla JavaScript in ES5 for you. You could try to convert the code with a compiler like Babel. Then it should work with midori.

Hey, @poekel

after some trying on my Baikal server, I found out, that just the use of the start parameter alone is not working indeed.

However, I was able to get a request, if you add the componentType option to the request URL. You have to filter the type to VEVENT. But thats no problem, because the documentation says, that this is the only working type for export anyway.

So I got valid answers with the following URL scheme (including recognized timestamp):

https://dav.example.com/dav.php/calendars/USERNAME/calendarname?export&start=1490745600&componentType=VEVENT

@TobiasAlw Ahh, I see. Yeah, this should work. Just add all the transportation types you don’t want to see to the excludedTransportationTypes string in your configuration.

All transportation types are listed here under “other parameters”.

@TobiasAlw could you please provide a link for me? Where can I find this feature in the vbb-rest documentation?

@poekel

I will try a request with a start parameter when I’m home and test if it works with my Baikal server.

For user credentials:

Just add user and pass to your calendar config like this:

config: {
    calendars: [
        {
		url: 'http://192.168.1.xx/baikal/html/dav.php/calendars/xxxx/calendar-name?export&start=1488672000',
		symbol: 'calendar',
		user: 'USERNAME',
		pass: 'PASSWORD'
        },
    ],
}

Additionally, Baikal uses Digest authentication. To use this, you have to change the sendImmediately option in the calendarfetcher.js to false. (As I already described above)

The option is located here. The file is located in MagicMirror/modules/default/calendar/calendarfetcher.js

In a future version of MM2, there will be an option for this directly in the config file so you don’t have to change this in calendarfetcher.js. I already submitted a pull request for that.

Hey @poekel
you have to use the keyword start instead of startdate.
It’s described in the sabre/dav documentation here: http://sabre.io/dav/ics-export-plugin/

So your request should look like this:
http://192.168.1.xx/baikal/html/dav.php/calendars/xxxx/calendar-name?export&start=1488672000

You can use this URL in your MM2 config file. It returns a valid .ics file. I’m using this on my mirror too.

And please note, that your calendar-name must be the internal name in Baikal (you can look this name up in the admin settings when you edit a calendar)