Feature #595

Add AES handling to sensor

Added by Hammel over 3 years ago. Updated about 2 years ago.

Status:ClosedStart date:28 Jul 2017
Priority:ImmediateDue date:
Assignee:Hammel% Done:


Target version:Iron Man - 0.5.0
Severity:01 - Critical


This is discussed in the communications protocols section of the MVP design document on the wiki.

Associated revisions

Revision ac4db7a8
Added by Hammel over 2 years ago

RM #595, RM #641, RM #646, RM#610: Implement better AES and Base64 encoding handling in send and receive functions. Verify requests come from registered monitor. Remove serialNotfiy() function and flags, replacing with proper timer-handler device registration. Lots of code cleanup.

Revision 02c2e57a
Added by Hammel about 2 years ago

RM #595, RM #664: Fixes to properly handle registration on reboot and AES message return on GET.
Move some stack variables to globals.
Add generateIV() to generate an IV for each outbound message.
Add generate_random_uint8() to generate random uint8 values.
Clean up handleDeviceGET() to properly encrypt and encode.
Return state data as encrypted and encoded JSON packet in handleDeviceGet().
Format SPIFFS when we complete registration to save registration data. Otherwise it may not have been formatted previously.
If we read registration data on boot, then mark us as registered.


#1 Updated by Hammel over 2 years ago

  • Status changed from New to In Progress
  • Priority changed from Normal to Immediate
  • % Done changed from 0 to 10
  • Severity changed from 03 - Medium to 01 - Critical

Bumping up because this is what will be implemented next.

#2 Updated by Hammel about 2 years ago

  • Description updated (diff)

#3 Updated by Hammel about 2 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 10 to 100

AES encryption and Base64 encoding added to the GET handler in imlightsw. Verified that it appears to do the right thing by using wget via the monitor to get the values manually. I can see the returned JSON string and it looks correct.

This is sufficient for this task. I'll need to create another task that allows Jarvis to request a state retrieval. RM #624 is for getting a device list. This new task will have to be done before that one is done. Or I might do them in parallel since they're very similar.

This other task will validate if the data returned can actually be deciphered.

Also available in: Atom PDF