@rosi8818
Eine häufige Stolperfalle ist der "Tagesvorschau"-Wert. Der Default ist nur auf wenige Tage gestellt. Wie du hier siehst, habe ich es z.B. bei mir auf 365 gestellt:

Ansonsten immer in den Logs schauen, ob dort etwas steht...

@rosi8818
Dafür sorgt der ical Adapter bereits. Wenn Du in das Skript genauer schaust, werden die Daten aus den ical.*.data.table Objekten ausgelesen, also aus ical.0.data.table, ical.1.data.table, usw. In jedem von diesen table-Objekten sind Daten aller Kalender enthalten.

@rosi8818
Versuche mal bei der ersten Spaltenbreite einen Wert höher 0 einzutragen:

@roko71
Dass das immer mehr Seiten machen, ist zuerst nicht überraschend, weil man mit dieser Einstellung bestimmte Security-Angriffsszenarien unterbinden kann. Nun, das bedeutet aber auch, dass die großen Vorteile der iFrames zunichte gemacht werden, bei allen, die nichts "Schlimmes" anstellen wollen :-(((
Eine Lösung, die in lokalen Netzen funktionieren könnte, wäre vielleicht mit Reverse-Proxies zu arbeiten, die den X-Frame-Options rausfiltern... Damit habe ich aber definitiv zu wenig Erfahrung... Aber vielleicht findet sich hier jemand im Form, der das schon gemacht hatte...

@RoKo71
Habe ich mir schon fas gedacht, dass es sowas ist...
Soweit ich es richtig verstehe, wird der Fehler auch immer kommen, wenn iobroker und loxone unterschiedliche IP-Adressen haben.
Hat loxone vielleicht irgendwo Einstellungen, um diesen Check zu deaktivieren (Header-Parameter "X-Frame-Options" wird auf "sameorigin" loxone-seitig gesetzt)?

@RoKo71
Was wird bei den Console-Ausgaben in den Chrome DevTools (F12) angezeigt?

@Scrounger
Habe jetzt verschiedene Möglichkeiten durchgespielt aber ich komme an einer Stelle nicht weiter, weil ich mehrere Tablets habe und die Logik Instanz-spezifisch ablaufen soll. D.h. ich möchte erreichen, dass die gesamte Logik nur auf dem Tablet greift, von dem der User die Aktion ge-triggered hat. Ich habe gehofft, dass ich mit dem Special Binding (https://github.com/ioBroker/ioBroker.vis#special-bindings) über
"{instance}" die aktuelle Instanz-ID bekomme und darauf basierend (über das Control Interface) ein Dialog auf dieser Instanz öffnen kann. Es scheitert aber schon daran, dass "{instance}" mir ein undefined liefert...

Du schreibst "...Dann ein Script, wenn sich der Wert ändert Dialog öffnen...".
Könntest Du mir etwas mehr Details geben, wie ein Skript aussehen würde, das dynamisch so ein Dialog öffnet?
Hast Du dabei auch an das Control Interface (https://github.com/ioBroker/ioBroker.vis#control-interface) gedacht oder kennst Du einen anderen Weg?

UPDATE:
Habe jetzt einen anderen Weg eingeschlagen und es folgendermaßen gelöst bekommen: ich generiere dynamisch per JS clientseitig jQuery-Dialoge, die ich per onClick-Events an die relevanten Zellen der Tabelle binde. Da es jetzt clientseitiges JS-Coding ist, ist damit auch gewährleistet, dass die Interaktion sich nur auf dem jeweiligen Tablet abspielt.

@Scrounger
Das Problem ist, dass der Dialog-Inhalt, der nach dem Klicken auf den Button angezeigt wird, pro Zeile spezifisch ist. Der Use-Case ist der folgende: ich kann bei der Anlage eines Kalendereintrages (z.B. im Google-Kalender) eine Beschreibung hinzufügen. Diese bekomme ich auch aus iCal in JS abgegriffen. Ich möchte aber diese Kalendereintrag-Beschreibungen nicht direkt in der Tabelle anzeigen sondern erst, wenn der User auf einen Button bzw. die Zeile klickt- also im geöffneten Dialog.
In anderen Worten, diese Kalendereintrag-Beschreibungen müssten Teil der JSON-Struktur sein, die schlussendlich als Inhalt des geöffneten Dialogs verwendet werden würden.

Das genannte "jqui - HTML - Dialog"-Widget hat ja ein "HTML im Dialog"-Feld, das diese Anforderung theoretisch erfüllen würde:

@Scrounger
Hallo, ich versuche pro Tabellenzeile weitere Details anzuzeigen, die nach einer User-Interaktion ge-triggered werden . Momentan habe ich es mir so vorgestellt, dass in jeder Zeile ein Button angezeigt wird oder aber der User direkt auf die gesamte Zeile klicken kann und dann wird ein Dialog mit weiteren Details, die zu dieser Zeile gehören, angezeigt.
Prinzipiell würde z.B. das "jqui - HTML - Dialog"-Widget die Anforderung erfüllen, allerdings müsste ja solches Nicht-MD-Widget in die JSON-Struktur kommen... Hast Du einen Tipp für mich, wie ich das umsetzen könnte?
Danke im Voraus

Ah, habe doch eine Lösung (oder vielleicht eher ein "Workaround") gefunden:
Man darf keine Default-View definieren, weil das Verhalten scheinbar so implementiert ist, dass bei der Änderung der aktuellen Auflösung automatisch zu der Default-View navigiert wird. Und da nach der Auswahl des Input-Feldes die Tastatur auf dem Tablet eingeblendet wird, ist das gleichbedeutend mit der Änderung der Auflösung (!), die wiederum zu der besagten Navigation führt.