eensymachines-in / luminapi Goto Github PK

This helps when we want to inspect the server output.
this though cannot be a public api

Check this - the ui does not appear correct in the full browser mode

PATCH  http://localhost/api/v1/devices/000000007920365y HTTP/1.1
Content-Type: application/json

{
    "serial":"000000007920365c",
    "scheds" : [
        {"on":"06:00 PM", "off": "06:00 AM", "primary":true, "ids":["IN1","IN2","IN3","IN4"]},
        {"on":"06:01 PM", "off": "06:10 PM", "primary":false, "ids":["IN1","IN2"]}
    ]
}

param serial = 000000007920365y , serial in payload = 000000007920365c
This has to be checked as an error and the request should be denied completion

The dark theme you are using is a bit offputting

Here we need to replace the old submit logic and put up a new one
Submit also needs to check if no schedule has zero lbl selection

https://youtu.be/AryZSCeKU9Y
Shows how a time picker can be a standard from html controls, we need not have custom controls with time picking.
This was actually naive of us to have a drop down to pick time

Watch these lines, when blacklisting the device(s) this though clears the device registration from the authapi database the device registration on luminapi device though is not changed. Ideally this should be cleared as well.
Blacking the device is often used to clear the registration before it gets assigned to a new owner. If the luminapi database isnt cleared the previous schedule and settings would be flow down into new registration. - Ideally a new in default setting shoudl take effect

Once we have set the changes to the list of schedules .. we need to dispatch the changes to the api

$provide.provider("baseURL", function(){
            // change this when the subdomain changes and all the services will follow
            this.$get = function(){
                return {
                    auth : "http://auth.eensymachines.in",
                    // TODO: before moving to production change this uri
                    lumin: "http://lumin.eensymachines.in/api/v1/devices",
                    cmds: "http://lumin.eensymachines.in/api/v1/cmds"
                    // lumin: "http://192.168.0.40/api/v1/devices",
                    // cmds: "http://192.168.0.40/api/v1/cmds"
                }
            }
        });

There has to be a better / dynamic way to do this

while the admin should be able to enlist the devices for the user, device details should not be accessible to admin

We need from the handheld user interface, a way to shutdown the device. This will post on the MQTT broker which will then callback the shutdown initiation

services:
  nginx:
    build: ./nginx
    ports:
      - "80:80"
    volumes: 
      # for local development the volume mapping changes
      # - "/home/niranjan/repos/eensymachines.in/luminapi/nginx/luminapp:/var/www/luminapp"
      - "/root/repos/eensymachines.in/luminapi/nginx/luminapp:/var/www/luminapp"

Its counter productive to change the volume definition everytime. need to pick this from environment file

currently we are working with #! which isnt quite convenient - need to switch to html5mode

Leaving the mqtt port directly open to vulnerabilities is not a good idea

We could have provided hardware to restart/ shutdown device. Adding hardware seems to be too mainstream and the whole idea of having an IoT device is to have maximum features operable from the handheld.
API needs to route the command to mqtt broker under a suitable topic so that device picks up and executes the same on priority

this is getting spaghetti and needs refactor and re-design

Speculation :

If before the submit we check for coflicts would it or not be convenient to the user ? and if it is then would the redundancy be worth the price of re-implementation in js. If the api incase of error already sends back the conflicting schedules, would it make more sense to use that feature to convey to the user the conflicting schedules ?

End goal : We need to indicate to the user of conflicting schedules, and this has been implemented already once on the server side

Double check the format of the time that is used in this package, Should be identical to the format of the time used in other packages

Modifying the schedules of a device is not apparently st. fwd Since the logic of applying schedules is a bit convoluted we needed to design the UI so that we insulate the end user from most of the drudgery and present a simple interface, yet get the required details everytime. Representing such data graphically is the next obvious choice.
Since time is not on our side at this juncture of prototype development, we have tried to fit the ui in bootstrap components.

since this is an API that we are building we need to be sure we pass on the err information thats compatible to log and debug

A unique identifier for the schedules is required

API has a face lift and schedules are sent out as device details. We have the relay maps and logs as well in the same payload. Prior to this we were only dealing with array of data as payload, but now we are expecting an object with all the device details