teal-mallet issueshttps://git.defproc.co.uk/ea/teal-mallet/-/issues2018-12-15T14:20:35Zhttps://git.defproc.co.uk/ea/teal-mallet/-/issues/11Can we make the server accept Date.toISOString()?2018-12-15T14:20:35ZAlex LennonCan we make the server accept Date.toISOString()?i.e. YYYY-MM-DDTHH:mm:ss.sssZ
Note the .sss for milliseconds. THis would mean I didn't have to frig the date in the node-red nodei.e. YYYY-MM-DDTHH:mm:ss.sssZ
Note the .sss for milliseconds. THis would mean I didn't have to frig the date in the node-red nodehttps://git.defproc.co.uk/ea/teal-mallet/-/issues/9If you run ansible too many times, you get rate limited on the certbot-auto s...2018-04-25T20:07:55ZPatrick FennerIf you run ansible too many times, you get rate limited on the certbot-auto scriptAnd it just hangs at that pointAnd it just hangs at that pointhttps://git.defproc.co.uk/ea/teal-mallet/-/issues/8Readings taken in the future bork the api2018-04-25T20:07:55ZPatrick FennerReadings taken in the future bork the apiWhen a device has measurements in the future (as compared to the server's time), calls to `/api/<entityId>/station/<deviceId>/measurements?start=all` return `502`.
Specifically, when the sensor time is set to BST (GMT+1) and the server is set to GMT, then no measurements display.
*NB: The incoming timestamps where reported as being GMT times — Z suffix.*
It's not clear if just waiting till after the last sensor reading time will clear this problem (I don't want to wait, and that doesn't work if the sensor is still transmitting), but ideally, the server should be agnostic about the date/time range of data that it holds. When a device has measurements in the future (as compared to the server's time), calls to `/api/<entityId>/station/<deviceId>/measurements?start=all` return `502`.
Specifically, when the sensor time is set to BST (GMT+1) and the server is set to GMT, then no measurements display.
*NB: The incoming timestamps where reported as being GMT times — Z suffix.*
It's not clear if just waiting till after the last sensor reading time will clear this problem (I don't want to wait, and that doesn't work if the sensor is still transmitting), but ideally, the server should be agnostic about the date/time range of data that it holds. JDJDhttps://git.defproc.co.uk/ea/teal-mallet/-/issues/4letsencrypt certificate location is hardcoded in deployment/webserver.yaml2018-04-25T20:07:55ZPatrick Fennerletsencrypt certificate location is hardcoded in deployment/webserver.yamlThis should probably be a variable in `hosts` or somewhere?This should probably be a variable in `hosts` or somewhere?https://git.defproc.co.uk/ea/teal-mallet/-/issues/3letsencrypt_renew.sh doesn't run on install2018-04-25T20:07:55ZPatrick Fennerletsencrypt_renew.sh doesn't run on installThere's no inital certificate installed when running ansible before it tries to start nginxThere's no inital certificate installed when running ansible before it tries to start nginxhttps://git.defproc.co.uk/ea/teal-mallet/-/issues/2some of the ansible playbook borks on raspbian2018-04-25T20:07:55ZPatrick Fennersome of the ansible playbook borks on raspbianspecifically:
```
- name: Set up locale
apt: pkg=language-pack-en state=present
become: true
# sudo locale-gen en_GB.UTF-8
post_tasks:
- name: Update locate database
shell: updatedb
become: true
```
then, even with those removed, it borks at:
```
fatal: [teal-mallet.local]: FAILED! => {"changed": false, "failed": true, "msg": "Wrong architecture 'amd64'"}
```
apparently this is influxdb not having arm compiled binaries
specifically:
```
- name: Set up locale
apt: pkg=language-pack-en state=present
become: true
# sudo locale-gen en_GB.UTF-8
post_tasks:
- name: Update locate database
shell: updatedb
become: true
```
then, even with those removed, it borks at:
```
fatal: [teal-mallet.local]: FAILED! => {"changed": false, "failed": true, "msg": "Wrong architecture 'amd64'"}
```
apparently this is influxdb not having arm compiled binaries
JDJD