Mojio - Connected Car

Anyone interested in writing a binding for Mojio connected car device? They have an open API, I would be willing to buy a unit for anyone who wanted to write a binding.

I wouldn’t be able to bite, as much as I would enjoy the project, but just to point out that such a binding could closely follow the patterns in the Ecobee binding, in order to deal with the sheer volume of data in and out. Essentially, OAuth2 token maintenance, a large domain model enforced by serializing and deserializing between JSON and JavaBeans, using Apache BeanUtils for simple access to set and get bean properties, and using BeanUtils converters to go between types like String, Integer, Boolean, etc., and StringType, DecimalType, SwitchType, etc. Easy to maintain, enforces the domain model, and pretty concise.

…also, the Nest binding is quite similar, just less of a volume of data than the Ecobee binding.

Well unfortunately, they are both over my head so I am looking for someone to write the binding. I thought I would try the list first rather then spending more money on getting someone outside of openhab up to speed.

Hi Nathan,

I work for moj.io and just wanted to give you a heads up that we actually have a simulator as part of our API; that should keep the costs low!

Check it here: https://developer.moj.io/simulator

Let me know if you have any questions about our API!

Cheers,

-Rob

@Rob_Chartier hmm, you work for moj.io and are on the OpenHab list! You open to writing a binding? :wink:

I was sad when I found out my Ford F-150 is not supported, however I found a developer and will proceed to write the binding.

@Rob_Chartier, how frequently do the devices update with the cloud?

Device update frequency depends on the state of the vehicle. When the ignition is on (a trip has started), we will send messages about once every 10 seconds. Otherwise will send it up at a much lower rate. Idle, towing, etc. are also events which we keep our eye on and blast the data up to the server.

There are also scenarios which the device will go into a deep sleep and really cut back on the number of messages it sends, just to save on battery power.

Obviously since we are using a cellular connection, if you decide to park underground it will most likely not communicate with our server at all. Once you get back into comm’s range, it will blast up all recorded activity.

BTW, what year is your F-150?

2013 Limited, Ford is the best selling truck in the U.S., sorta suprised you did not support it.

Is there a way to increase that? 10 sec is a long time compared to real time.

BTW, We do have a plethora of F-150s already running mojio’s with lots of success, including the 2013 year.

Accelerometer, Battery, Fuel Efficiency (depending on year), GPS/Location, Heading (depending on year), RPM, Speed, Service Bulletins, Recalls, Towing, Odometer (depending on year).

Since we are a cellular based device we have actually throttled back the frequency, and are trying to strike a balance between that and costs.

Keep in mind our business model is not really geared towards high-frequency data collection and aggregation from OBD devices. But it is fantastic for something like a geo-fence around your house where you want to trigger a scene…

I now have a mojio binding, let me know if anyone is interested.

13:33:03.211 [INFO ] [runtime.busevents :26 ] - FuelLevel state updated to 62.7000000000000028421709430404007434844970703125
13:33:03.617 [INFO ] [runtime.busevents :26 ] - LocationLng state updated to -77.9092700000000064619598560966551303863525390625
13:33:03.894 [INFO ] [runtime.busevents :26 ] - VehicleName state updated to F150
13:33:04.335 [INFO ] [runtime.busevents :26 ] - LocationLat state updated to 39.48566000000000286718204733915627002716064453125

That’s great news!

Perhaps the developer could use Java’s BigDecimal for any representation and computation of decimal numbers, to eliminate the false precision caused by standard IEEE floating point’s inability to exactly represent all numbers?

Also, if the binding were to offer an item in lat,lng[,alt] format (meaning altitude is an optional third value) and provide updates to Location items using PointTypes, you could track your car on a map in the classic (and other) UIs!

Then some day, you could send your car a PointType command to have it come pick you up.

Will let him know about the BigDecimal thing, but I am not sure I understand the PointTypes stuff. Do you have any examples?

Location MyTruckLoc { mojio="how to get a lat,long from the binding" }

The binding would take “how to get a lat,long from the binding” and post an update of new PointType("<actual_lat>,<actual_long>") if it’s bound to a LocationItem. If it’s instead bound to a String item, the binding would just post an update of new StringType("<actual_lat>,<actual_long>").

The point of the Location item is that the classic UI, and hopefully other and more UIs, will properly render an actual map with a pin to show where your truck is (as of openHAB 1.8 or recent builds, but your binding won’t become 1.8-specific by doing the above). That’s all you need to do.

Example from OH1.8 Classic UI (String item followed by a Location item):

Great, I will have him add that, also having him add a units flag in openhab.cfg because right now it returns things in metric and I live in backwards US.

Any way to have more then one point show up on a map?

Perhaps he could add an optional transform to the binding string, so you could append :JS(c_to_f.js) to what you currently supply, and write your own conversion in a simple line of JavaScript. Lots of other bindings do that sort of thing. More capability down the road by empowering users to transform values themselves.

Not that I’m aware of. It might make sense to add a new Map element to sitemaps:

Map [item=<itemname>]

where <itemname> could refer to a Location or a Group item. In the case of a Group item, all Location items in the group would be shown on the same map, with the <itemname>s’ labels. Just a thought. For now, I’m not aware of a non-very-complicated way.

My current setup just renders a Group of items and the Location item is in that group, so there is no specific sitemap entry.

The following items and rule would (in theory) give you the current distance between your truck and home in openHAB 1.8:

items:

Location TruckLoc { mojio="how you get lat,long from mojio" }
Number TruckDistFromHome

rule:

import org.openhab.core.library.types.*

rule DistanceFromHome
when
  Item TruckLoc changed
then
  var PointType home = new PointType("<homelat>,<homelong>")
  var DecimalType dist = home.distanceFrom(TruckLoc.state)
  // dist is meters; divide by 1609.34 for miles
  TruckDistFromHome.postUpdate(dist)
end

I will give it a try! So far I have:

Main Menu.pdf (104.5 KB)