search

0ff / long-live-sense

As Hello said Goodbye, this repo is in an effort to keep the Hardware alive
MIT License
18 stars 1 forks source link

Contact with James Proud (www.sense.is) #2

Open luc-ass opened 6 years ago

luc-ass commented 6 years ago

Hey there,

I just contacted James Proud via E-Mail and he is willing to change DNS-entries for sense.is if we provide him with details so we can potentially start server communications. As I do not have really great expertise, I'd like to ask you wether this would be of any help.

Thanks and let's hope we can get this great piece of hardware to work again!

Lucas

tshimkus commented 6 years ago

I'm very much a novice at IoT applications and mobile app development but I may be able to lend a hand on the API side of things.

It may not be sustainable to host the app to operate over the cloud as it was during production. I imagine there was a steady bombardment of data streaming between mobile devices and Sense hardware.

Has anybody looked into running the application locally (end user mobile device and/or Sense device)?

luc-ass commented 6 years ago

My idea was, that as soon as we could get hold of a valid TLS 1.2 CERT, we could host a server and make a modified firmware available. One where you could actually specify a local host (i.e. docker container) to run sense - or just pull data from the device.

The sense has an 8GB flash card installed - so there should be more than enough space to store historical data if it doesn't need 5 sec granularity.

MrTeal commented 6 years ago

First of all, nice going! This gives me hope that the sense will become usable again. Hopefully we don't need the app to install the new firmware though, it has been pulled from the App Store, at least on iPhone. I recently had to reinstall my phone and the app was no longer available... But maybe it can be accessible from a (local) website or something.

Firehed commented 5 years ago

@luc-ass I think that approach could work well. If someone is able to modify (and presumably sign) the firmware to some sort of jailbroken version (if you will), hosting something shouldn't be too terrible, and getting SSL certs shouldn't be an issue if they are willing to update the DNS for us.

I'd be willing to host something if it's not resource-intensive (i.e. a firmware update manifest is probably fine, but definitely not the API backend), but I don't have the time or expertise to do any of the firmware modification stuff. If others are willing to figure out that side, let me know and I'll offer what I reasonably can.

darthlotus commented 5 years ago

Cant app be edited to be stand alone? Remove login, wifi, and therein need for server an all that crap, There are other apps out now that do all that monitoring, analysis stuff, Most of us just want to be able to use the device, better a fancy alarm clock than an ornament

jhoogeboom commented 4 years ago

I'm a bit late to this party, have you considered re-flashing the main mcu with an edited version where the endpoints go to wherever you want? Except for time.hello.is they are even nicely grouped together: https://github.com/hello/kitsune/blob/6a28afa80dd4547907e58341a84bd0b5bec5d88e/kitsune/endpoints.h

Did anyone look into what is minimally needed to run the backend? Seems like quite a bit of services by the amount of repos.

Qianli-Ma commented 4 years ago

I'm a bit late to this party, have you considered re-flashing the main mcu with an edited version where the endpoints go to wherever you want? Except for time.hello.is they are even nicely grouped together: https://github.com/hello/kitsune/blob/6a28afa80dd4547907e58341a84bd0b5bec5d88e/kitsune/endpoints.h

Did anyone look into what is minimally needed to run the backend? Seems like quite a bit of services by the amount of repos.

Re-flashing the MCU by using jtag?

jhoogeboom commented 4 years ago

That could be an option, but I think they might have a UART on there that can be used to flash it? Anyway I should take a look at the schematics and do some testing.

Qianli-Ma commented 4 years ago

That could be an option, but I think they might have a UART on there that can be used to flash it? Anyway I should take a look at the schematics and do some testing.

Any updates by chance?

jhoogeboom commented 4 years ago

Nope, have to find some time, did you try jtag?

jdtzmn commented 4 years ago

@jhoogeboom it's nice to see some updates on this. If one of you managed to flash the firmware I would lend some time to the software side of things. Keep me posted- I really miss my sense.

jhoogeboom commented 4 years ago

Will let you know, cheers for lending some time on the software side of things. It looks like a decent bit of infrastructure, quite a bunch of (micro)services.

MrTeal commented 3 years ago

Came across my old Hello Sense Orb in a drawer and started looking if there was any progress on flashing it to add it to home assistant or something. Did you guys make any progress or has everybody given up on it?

jhansche commented 3 years ago

I got in contact with a former engineer, and he helped me put together a UART cable that works correctly to read the debug console and issue cli commands. He also helped me get my build environment set up and I was able to build the firmware image for flashing.

The problem now is I can't get the device to enter programming mode, following his recollection and reverse engineering one of their original dev cables, which has a switch on it to toggle between debug mode and programming mode. He tested the cable again on his own Sense and it still works, so I must be doing something wrong, or my cable or TTL chip isn't right.

If you have a newer firmware, there might be one command (x) that can be used to download a firmware image and store it into the correct flash location, but my firmware is old and doesn't have that command.

I haven't had time to get back to it since then. I was hoping to verify that I can recreate the programming cable, before putting together some instructions to add here. But since my cable doesn't work to enter programming mode, I haven't done that yet.

My plan was to add mqtt support to the device to add it to home assistant. But first I wanted to verify that I can flash it at all before I start doing that.

MrTeal commented 3 years ago

Seems you got pretty far though, if you ever get it to work I'd like to hear about it 😊

jhansche commented 3 years ago

For those that want to get the debug cable working, you need:

  1. a USB micro-B cable connector with the "ID" pin (pin 4) connected to a wire inside the cable, not short circuited anywhere or grounded. In particular, note that a "USB-OTG" cable will typically have pin 4 shorted to ground, because that's a requirement of OTG. That will work for the debug console, but it will not work for programming.
  2. an FTDI UART/TTL converter or cable, 5V. I got 3 different varieties of chip, but only one worked reliably -- one was DOA, and the other worked okay for debug comms, but I don't think it would work for programming.
  3. make the following connections between the UART converter and micro USB pins:
    • UART 5V VCC -> USB VCC pin 1
    • UART GND -> USB GND pin 5
    • UART TXD -> USB D- pin 2
    • UART RXD -> USB D+ pin 3
  4. The "magic" to switch between debug/programming mode happens on pin 4, also known as "ID" or "SENSE" wire. This is usually used for OTG sensing, to see if there's a peripheral device attached or not. Based on reverse engineering his dev cable, we found that when it is flipped to debug mode, it sends pin 4 to GND, and this causes the device to enter the debug cli mode; flipped the other way to programming mode, it sends pin 4 to 5V power. Since the debug mode is the only one I've gotten to work, that's all I can say for sure: pin 4 to GND = debug/cli console mode.

So with everything connected like that (and pin 4 to GND), fire up your terminal emulator, and set baud to 115200. If USB-ID pin 4 is connected to GND when it powers up, you'll know it's in the debug console mode by the swirling yellow LED in the Sense.

If you power it up with the cable connected and terminal emulator already running, you should see a boot log print to the console. For this reason, I left the UART chip connected to my computer, and had another way to toggle power (and ground) to the Sense -- in my case, I used a breadboard to manage the connections, which means I could toggle power separately, and I could move USB-ID pin 4 between ground, hi-z (floating), or power.

If you weren't already watching the console when it powered up, press enter a few times and you should see a > cli prompt, where you can enter commands.

You can find the full list of commands at https://github.com/hello/kitsune/blob/master/kitsune/commands.c#L2005-L2007 Issue command nwp to get a summary of the versions on the device. Here is my nwp output:

> nwp
FW 1.4.0.1.
PHY 1.0.3.34.
CHIP 4000010
NWP 2.6.0.5.
ROM 3333

And this is a full boot log:

Boot
*****************************priority check 200191fd 0

FreeRTOS V8.2.3, 000011a1,  f4:b8:5e:xx:xx:xx
FW 1.4.0.1.
PHY 1.0.3.34.
CHIP 4000010
NWP 2.6.0.5.
ROM 3333
> GET DEVICE ID
spiwrite: 0Sending BLE 10
got SYNC_DEVICE_ID
got id from top fa:5b:33:39:xx:xx:xx:xx
spiwrite: 0Sending BLE 22

Top Board Version is 1.0.3
Fit to 13 Bytes
got SYNC_DEVICE_ID
got id from top fa:5b:33:39:xx:xx:xx:xx
spiwrite: 0Sending BLE 22

Top Board Version is 1.0.3
Fit to 26 Bytes
Analytics: {ble_mode: 3}{ble_mode: 3}
NT /logs
NT: queued back

If you have an older version of the Sense firmware, like I do, then the commands listed above are not accurate, because that's from the latest and greatest master branch. The commands that work on my device are better represented by an older commit in the repo: https://github.com/hello/kitsune/blob/d3dc40aa27a874034b9250c4faf4a3dd9e4acd11/kitsune/commands.c#L1953

Also note that with this command console, you still have access to the sensor data, so in theory you could hook it up to a raspberry pi, with this UART console connection, and have the Pi control the device using CLI commands and read sensor data using commands and parsing the response:

There's a lot more in the commands table. Be aware that the power draw might be too much for a Raspberry Pi to handle on its own, so you might need to rig an extra standalone power source so that you're not overdrawing 5V from the Pi. Then all you need is the D-/D+ pins going to TXD/RXD. On my breadboard I have a standalone switched power supply that plugs right onto the breadboard, so I can easily toggle power without unplugging my UART converter.

I know it sounds like a lot of progress (I guess since we've so far gotten nothing in the last 5 years, it's infinite progress!), but it's not quite what I was hoping for, because I wanted to flash a custom firmware so that I could use it standalone. The cli debug console was exciting when I got it working, but it will require a connection to a terminal for it to be usable. And the console is not exactly stable -- some commands put it into a frozen state and you have to toggle power to reboot it and get the console back.

MrTeal commented 3 years ago

Wow, that's some nice work, furthest I've seen anyone got and who posted about it on Git at least. When I connect my Sense to my laptop it starts the yellow led swirl automatically, but I've not been able to connect to it. Maybe I can give it a shot using your instructions.

jhansche commented 3 years ago

Yeah, the yellow swirling LED means it's currently sitting in the debug command console mode, waiting for commands over the UART serial port. If you instead connect it to the power adapter wall wart (not to a computer), it would try to boot up normally, rather than in the debug console mode. It's when it's connected to a computer's USB port (or this debug/programming UART cable) that it goes into that debug mode.

If you connect a UART serial debugging cable to it, with an FTDI converter chip or cable, you should be able to see the debug command console on the usbserial COM port.