Provide daily and manual trigger JSON export for sales and stats?

[MeisterAdebar]

Hi,

Not essential, but it would be nice to have the option to get revenue and statistics data as a JSON file, on a daily schedule and via a manual trigger.
Just a helpful addition if feasible—no pressure.

[developeregrem]

Hi, all endpoints of the statistic pages provide json output already. It's used to render the charts.
E.g.:
https://<host>/statistics/utilization/monthtly?objectId=all&monthStart=1&monthEnd=1&yearStart=2026&yearEnd=2026
You can use the developer console in the browser to see the requests.
Maybe it will be helpful already?

[MeisterAdebar]

This is really cool - it enables me to implement everything I had in mind ;)

Thanks a lot for your work...

[MeisterAdebar]

However, fetching the JSON endpoints seems to require an active browser session, as simple attempts via Basic Auth are being ignored or redirected.

In Perl, I am using the HttpUtils_NonblockingGet function. My current code looks like this, where I have to rely on manually copied cookies to prevent the Symfony security layer from redirecting the request to the login page:

Perl

sub TransformUtilization {
    # My attempt with Basic Auth (fails / is ignored):
    # my $auth = encode_base64("bli:bla!");
    
    # Current unstable workaround via browser session cookies:
    my $all_cookies = 'PHPSESSID=52d80051...; REMEMBERME=App.Entity.User...';
    
    HttpUtils_NonblockingGet({ 
        url => "https://fhempi/statistics/turnover/monthly?...",
        header => "Cookie: $all_cookies",
        callback => sub {
            return if $_[1];
            Debug $_[2]; 
        }
    });
}

Since these session cookies (especially the PHPSESSID) expire regularly, this integration is very high-maintenance.

After my first few attempts, I am a bit unsure if I simply failed to implement Basic Auth correctly on my end or if the endpoint is not configured to support it.

My question: Is there a recommended method for programmatic access (e.g., a dedicated API key / Personal Access Token), or would it be possible to implement token-based authentication (e.g., via Authorization: Bearer ) for the statistics exports?

[developeregrem]

Hi,
yes default session is valid for 30 minutes I guess and basic auth is not activated. At the moment only form login and passkeys are allowed. Due to security reasons basic auth will be not implemented, but I will add the api and authorization header on the roadmap.
In the meantime you can play a bit with the rememberme cookie. Just leave the phpsess cookie and use only rememberme. In my short tests it was working by requesting a json endpoint using the rememberme cookie only. The rememberme cookie is valid for one year by default.

[MeisterAdebar]

First of all, a big thank you for implementing the many change requests over the past weeks — that’s really not something to be taken for granted and is very much appreciated!

And yes: it works with only the rememberme cookie. Thanks.

[daking88]

Wenn ich da auch noch einsteigen darf: die Endpunkte hatte ich mir auch schon länger angesehen, was ich vermisse, ist einer, der einfach alle Reservierungen zurückgibt, damit man ggfs. noch einmal eigene Auswertung (Durchschnittliche Anzahl Übernachtungen / Preis, ... usw) machen kann. Die bisherigen Endpunkte sind ja schon recht aggregiert... Oder habe ich einen übersehen, @developeregrem?

[developeregrem]

Hi, das ist sehr wahrscheinlich der Fall. Mir fällt aktuell auch keine Stelle ein, wo das möglich wäre. Wird alles im Backend gefiltert. Die aktuellen Endpunkte bedienen halt das was die UI anzeigen soll. Der API Ansatz war damals kein Ziel und entsprechend nicht direkt von der Architektur vorgesehen. Bei allem was etwas neuer ist, wie die Statistik, hatte ich versucht das direkt so zu bauen. Evtl. werde ich in der Zukunft nochmal überlegen, wie hier ein redesign aussehen könnte, um das nachhaltig zu lösen. Das wird aber vermutlich nichts in naher Zukunft.
Der aktuell einzige Weg an mehr Reservierungen zu kommen, wäre über das Betriebs PDF Template. Da bekommst du alle im ausgewählten Zeitraum und kannst damit machen was du möchtest. Nicht das gleiche aber dafür hast du ein hübsches PDF am Ende 😎

[MeisterAdebar]

Hi,

komm ich irgendwie an vergleichbare Werte wie sie die Rezeption Checkliste liefert oder nicht?

Gruß Thomas

[developeregrem]

Aktuell leider nicht. Da wird viel im Backend gemacht und nirgends so bereitgestellt, wie du es vermutlich brauchst.

[MeisterAdebar]

... wie du es vermutlich brauchst

Wie is mir Wurscht, Hauptsache irgendwie!
Wenn es nicht anders geht, beschäftige ich mich damit, mir die Daten direkt aus der Datenbank zu holen...

[MeisterAdebar]

Hi,

ich hab zwei kleine API-Endpoints bauen lassen um Reservierungsdaten als JSON abzurufen:

• GET /api/reservations/current – aktuell belegte Zimmer
• GET /api/reservations/arrivals – heutige Anreisen

Kannst Dir vorstellen das zu übernehmen bis es mal eine Lösung von dir gibt?

[MeisterAdebar]

Am liebsten wäre mir ja, wenn die Daten gepusht und nicht gepollt werden müssen.

Bin mir aber unsicher ob solch ein Feature überhaupt erwünscht ist?

https://github.com/MeisterAdebar/fewohbee/tree/feature/mqtt-integration

define fewohbee_zimmer_1 MQTT2_DEVICE fewohbee_zimmer_1
attr fewohbee_zimmer_1 readingList fewohbee/zimmer/1:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_1 room MQTT2_DEVICE

define fewohbee_zimmer_2 MQTT2_DEVICE fewohbee_zimmer_2
attr fewohbee_zimmer_2 readingList fewohbee/zimmer/2:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_2 room MQTT2_DEVICE

define fewohbee_zimmer_3 MQTT2_DEVICE fewohbee_zimmer_3
attr fewohbee_zimmer_3 readingList fewohbee/zimmer/3:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_3 room MQTT2_DEVICE

define fewohbee_zimmer_4 MQTT2_DEVICE fewohbee_zimmer_4
attr fewohbee_zimmer_4 readingList fewohbee/zimmer/4:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_4 room MQTT2_DEVICE

define fewohbee_zimmer_5 MQTT2_DEVICE fewohbee_zimmer_5
attr fewohbee_zimmer_5 readingList fewohbee/zimmer/5:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_5 room MQTT2_DEVICE

define fewohbee_zimmer_6 MQTT2_DEVICE fewohbee_zimmer_6
attr fewohbee_zimmer_6 readingList fewohbee/zimmer/6:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_6 room MQTT2_DEVICE

define fewohbee_zimmer_7 MQTT2_DEVICE fewohbee_zimmer_7
attr fewohbee_zimmer_7 readingList fewohbee/zimmer/7:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_7 room MQTT2_DEVICE

define fewohbee_zimmer_8 MQTT2_DEVICE fewohbee_zimmer_8
attr fewohbee_zimmer_8 readingList fewohbee/zimmer/8:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_8 room MQTT2_DEVICE

define fewohbee_zimmer_9 MQTT2_DEVICE fewohbee_zimmer_9
attr fewohbee_zimmer_9 readingList fewohbee/zimmer/9:.* { json2nameValue($EVENT) }
attr fewohbee_zimmer_9 room MQTT2_DEVICE

setstate fewohbee_zimmer_1 2026-06-30 13:00:08 IODev MQTT2_Server
setstate fewohbee_zimmer_1 2026-06-30 13:00:09 associatedWith fewohbee
setstate fewohbee_zimmer_1 2026-06-30 14:13:52 endDate 2026-07-02
setstate fewohbee_zimmer_1 2026-06-30 14:13:52 name  Test1
setstate fewohbee_zimmer_1 2026-06-30 14:13:52 startDate 2026-06-30
setstate fewohbee_zimmer_1 2026-06-30 14:13:52 status anreise

setstate fewohbee_zimmer_2 2026-06-30 13:00:09 IODev MQTT2_Server
setstate fewohbee_zimmer_2 2026-06-30 13:00:15 associatedWith fewohbee
setstate fewohbee_zimmer_2 2026-06-30 14:13:07 endDate 2026-06-30
setstate fewohbee_zimmer_2 2026-06-30 14:13:07 name  Test3
setstate fewohbee_zimmer_2 2026-06-30 13:18:03 startDate 2026-06-29
setstate fewohbee_zimmer_2 2026-06-30 14:13:07 status abreise

setstate fewohbee_zimmer_3 2026-06-30 13:00:09 IODev MQTT2_Server
setstate fewohbee_zimmer_3 2026-06-30 13:00:15 associatedWith fewohbee
setstate fewohbee_zimmer_3 2026-06-30 13:14:56 status frei

setstate fewohbee_zimmer_4 2026-06-30 13:00:10 IODev MQTT2_Server
setstate fewohbee_zimmer_4 2026-06-30 14:15:16 arriving_endDate 2026-07-01
setstate fewohbee_zimmer_4 2026-06-30 14:15:16 arriving_name  Test3
setstate fewohbee_zimmer_4 2026-06-30 14:15:16 arriving_startDate 2026-06-30
setstate fewohbee_zimmer_4 2026-06-30 13:00:15 associatedWith fewohbee
setstate fewohbee_zimmer_4 2026-06-30 14:15:16 departing_endDate 2026-06-30
setstate fewohbee_zimmer_4 2026-06-30 14:15:16 departing_name  Test1
setstate fewohbee_zimmer_4 2026-06-30 13:53:08 endDate 2026-06-30
setstate fewohbee_zimmer_4 2026-06-30 13:53:08 name  Test1
setstate fewohbee_zimmer_4 2026-06-30 13:53:08 startDate 2026-06-29
setstate fewohbee_zimmer_4 2026-06-30 14:15:16 status wechsel

setstate fewohbee_zimmer_5 2026-06-30 13:00:11 IODev MQTT2_Server
setstate fewohbee_zimmer_5 2026-06-30 13:00:15 associatedWith fewohbee
setstate fewohbee_zimmer_5 2026-06-30 13:14:56 status frei

setstate fewohbee_zimmer_6 2026-06-30 13:00:12 IODev MQTT2_Server
setstate fewohbee_zimmer_6 2026-06-30 13:00:16 associatedWith fewohbee
setstate fewohbee_zimmer_6 2026-06-30 13:14:56 status frei

setstate fewohbee_zimmer_7 2026-06-30 13:00:12 IODev MQTT2_Server
setstate fewohbee_zimmer_7 2026-06-30 13:00:16 associatedWith fewohbee
setstate fewohbee_zimmer_7 2026-06-30 14:17:58 endDate 2026-07-01
setstate fewohbee_zimmer_7 2026-06-30 14:17:58 name  Test3
setstate fewohbee_zimmer_7 2026-06-30 14:17:58 startDate 2026-06-30
setstate fewohbee_zimmer_7 2026-06-30 14:17:58 status anreise

setstate fewohbee_zimmer_8 2026-06-30 13:00:13 IODev MQTT2_Server
setstate fewohbee_zimmer_8 2026-06-30 13:00:16 associatedWith fewohbee
setstate fewohbee_zimmer_8 2026-06-30 13:18:03 endDate 2026-07-02
setstate fewohbee_zimmer_8 2026-06-30 13:18:03 name  Test2
setstate fewohbee_zimmer_8 2026-06-30 13:18:03 startDate 2026-06-29
setstate fewohbee_zimmer_8 2026-06-30 13:18:03 status belegt

setstate fewohbee_zimmer_9 2026-06-30 13:00:14 IODev MQTT2_Server
setstate fewohbee_zimmer_9 2026-06-30 13:00:16 associatedWith fewohbee
setstate fewohbee_zimmer_9 2026-06-30 13:18:03 endDate 2026-07-02
setstate fewohbee_zimmer_9 2026-06-30 13:18:03 name  Test2
setstate fewohbee_zimmer_9 2026-06-30 13:18:03 startDate 2026-06-29
setstate fewohbee_zimmer_9 2026-06-30 13:18:03 status belegt

[developeregrem]

Moin,
interessanter Ansatz via mqtt. Hatte ich jetzt ehrlich gesagt nicht geplant so etwas einzubauen.
Du könntest das das aber gerne federführend einbauen und testen. Da ich selbst keinen use case dafür habe kann ich da wenig beisteuern. Ich habe die Umsetzung jetzt nur grob überflogen aber hier noch ein paar Punkte, die mir bei neuen Features wichtig sind:

• saubere, erweiterbare Grundarchitektur, die zur restlichen Anwendung passt
• Logik, wenn möglich aus vorhandenen Services Wiederverwenden. Das Rad nicht neu erfinden.
• Die Umsetzung sollte generisch sein, sodass viele Nutzer etwas davon haben, sofern sie es nutzen wollen. Keine Insellösung
• an Mehrsprachigkeit denken (min de und en immer pflegen)
• Sicherheit: ist mir persönlich eines der wichtigsten Themen. Die Umsetzung muss robust und sicher sein
• alles mit Unit/functional tests absichern
• gute wartbarkeit, also auch gerne mal den ein oder anderen Kommentar bei komplexeren Sachen ergänzen. Ich will bei allen Methodensignaturen eine kurze Beschreibung was die Methode macht. Kommentare in englisch

Ich glaube das sind so die wichtigsten Punkte 🙃
Also von mir aus kannst du da gerne weitermachen.
Das mit der API könnte man für den Anfang so machen aber die Wahrscheinlichkeit, dass ich das später wieder umbaue ist recht hoch.

VG
Alex

[MeisterAdebar]

• saubere, erweiterbare Grundarchitektur, die zur restlichen Anwendung passt
• Logik, wenn möglich aus vorhandenen Services Wiederverwenden. Das Rad nicht neu erfinden bei mir.

Du hast es diesbezüglich mit einem Chaoten zu tun, also bei mir besser immer zweimal hinschauen.

• Die Umsetzung sollte generisch sein, sodass viele Nutzer etwas davon haben, sofern sie es nutzen wollen. Keine Insellösung

Seh ich genauso. Ich bin der Meinung das in der ersten Fassung schon ein zwei Punkte besser umgesetzt wurden wie in anderen Projekten.

• an Mehrsprachigkeit denken (min de und en immer pflegen)

Gleich nach dem commit dachte ich mir eigentlich die Übersetzungen nehm ich wieder raus.
Es wird nur in Englisch gepublisht. Was der User draus macht ist seine Sache und spart Arbeit.

• Sicherheit: ist mir persönlich eines der wichtigsten Themen. Die Umsetzung muss robust und sicher sein

Was soll ich dazu sagen als Laie?

• alles mit Unit/functional tests absichern

Damit mag ich mich beschäftigten/hab ich schon.

• gute wartbarkeit, also auch gerne mal den ein oder anderen Kommentar bei komplexeren Sachen ergänzen. Ich will bei allen Methodensignaturen eine kurze Beschreibung was die Methode macht. Kommentare in englisch

Schon ergänzt bei mir.

• Das mit der API könnte man für den Anfang so machen aber die Wahrscheinlichkeit, dass ich das später wieder umbaue ist recht hoch.

Dann meinen Gedanken dazu verwerfen. Mich mit beidem (Api und Mqtt) zu beschäftigen ist mir too much.

[MeisterAdebar]

Für eine dauerhafte Verbindung soll es zwei Wege geben:

• Dauerhafter MQTT-Client als Symfony-Service der beim App-Start verbindet
• Oder als separater Symfony Messenger Worker/Command der dauerhaft läuft

Für welchen sollte ich mich entscheiden.

edit:

Variante 2 soll für Fewohbee architektonisch der richtige Weg sein, aber deutlich mehr Aufwand. Variante 1 soll in PHP grundsätzlich nicht wie von mir erwartet laufen.