Fix door sensor endpoint #105

Closed
opened 2026-01-09 19:04:36 +01:00 by oysteikt · 7 comments
Owner

There is likely a mismatch between the expected schema and the schema used in the prod database

Screenshot sent by @berntjd in maintenance discord channel

There is likely a mismatch between the expected schema and the schema used in the prod database Screenshot sent by @berntjd in maintenance discord channel
oysteikt added the bugcrash report labels 2026-01-09 19:04:36 +01:00
Owner

It looks like the correct payload format for https://git.pvv.ntnu.no/Projects/nettsiden/src/branch/main/www/door/index.php#L64-L81, and used to work fine.

There is likely a mismatch between the expected schema and the schema used in the prod database

Has the door table been dropped or altered, and if so, why? Taking a look.

It looks like the correct payload format for https://git.pvv.ntnu.no/Projects/nettsiden/src/branch/main/www/door/index.php#L64-L81, and used to work fine. > There is likely a mismatch between the expected schema and the schema used in the prod database Has the door table been dropped or altered, and if so, why? Taking a look.
Owner
MariaDB [www-data_nettside]> SELECT * FROM door ORDER BY time DESC LIMIT 3;
+------------+------+
| time       | open |
+------------+------+
| 1767079800 |    0 |
| 1767078900 |    0 |
| 1767078000 |    0 |
+------------+------+
3 rows in set (0.000 sec)

Well, the table exists and looks sane, and stops at 1767079800, which is Tuesday, December 30, 2025 8:30:00 AM (Norwegian time)

``` MariaDB [www-data_nettside]> SELECT * FROM door ORDER BY time DESC LIMIT 3; +------------+------+ | time | open | +------------+------+ | 1767079800 | 0 | | 1767078900 | 0 | | 1767078000 | 0 | +------------+------+ 3 rows in set (0.000 sec) ``` Well, the table exists and looks sane, and stops at 1767079800, which is `Tuesday, December 30, 2025 8:30:00 AM` (Norwegian time)
Author
Owner

No, I think it's the code that queries the database, I suspect I switched out INT for DATETIME or something similar

No, I think it's the code that queries the database, I suspect I switched out INT for DATETIME or something similar
Author
Owner

Did some more research, everything seems to match in the code and the production db, I wonder what's up...

If the door sensor stops at december 30, and we don't have any data since then, could it be that the php code crashes when it queries 0 rows?

Did some more research, everything seems to match in the code and the production db, I wonder what's up... If the door sensor stops at december 30, and we don't have any data since then, could it be that the php code crashes when it queries 0 rows?
Author
Owner

No wait, I'm dummedumm, this is the other part of the code that sends in timestamps. uuuuuuh, lemmesee

No wait, I'm dummedumm, this is the other part of the code that sends in timestamps. uuuuuuh, lemmesee
Author
Owner

There was indeed a type bug though, assuming an immutable date time was an int and stuff

There was indeed a type bug though, assuming an immutable date time was an int and stuff
Author
Owner

Should be fixed now

Should be fixed now
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Projects/nettsiden#105