ESPEasyRV Electronical Upgrade of a Motorhome

Moderators: grovkillen, Stuntteam, TD-er

Message
Author
Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

ESPEasyRV Electronical Upgrade of a Motorhome

#1 Post by Wiki » 03 Jun 2020, 15:18

I started a project to replace my 16 years old self built onboard "computer" of my motorhome (I was / am using a Tiny Tiger) by something little bit more modern.

Some pictures of the old electronics, self-soldered, the battery sensor self designed and built on selfmade pcb board, read using AD, an old modified USB GPS mouse attached to serial port, huge amount of spaces used, bunch of cables through the whole motorhome. But it worked through the past 15 years reliably without any changes except the addition of two NTC resistors to get and display inside/outside temperatures (not to be seen on the old pictures I took 16 years ago, sorry), the data are downloadable using a serial cable to the laptop.
Murphyalt7.jpg
Murphyalt7.jpg (99.47 KiB) Viewed 3564 times
Murphyalt6.jpg
Murphyalt6.jpg (98.93 KiB) Viewed 3564 times
Murphyalt5.jpg
Murphyalt5.jpg (99.6 KiB) Viewed 3564 times
Murphyalt1.jpg
Murphyalt1.jpg (97.94 KiB) Viewed 3564 times
Murphyalt2.jpg
Murphyalt2.jpg (98.57 KiB) Viewed 3564 times
Murphyalt3.jpg
Murphyalt3.jpg (98.35 KiB) Viewed 3564 times


In this current project which I name ESPEasy-RV I want to collect all data of my motorhome I could get, i.e. level of water tank, level of LPG tank, battery states, solar panel energy production, levelling of the vehicle itself, track trips, display time and ambient data, aso. The amount of sensors needed took me to the decision to realize it using ESPEasy. This will reduce the weight of the motorhome by a ton of copper cables, increase the amount of data collectable, give much more precise readings. And last but not least, it will increase the WAF of my doing as already happened with my installations in my house/living room.

This project will be steadily growing. At first I want to implement the features of my old Tiny Tiger which are battery state monitoring (voltage/current/power/remainig capacity), trip tracking and inside/outside temperatures.

So, lets start.

Equipment currently used: Huawei mobile 4G Hotspot, three Wemos D1, one for the GPS sensor, one for a MPU6050 gyro and a BMP280, one for a 4.3" Nextion display.

The first steps are done, I will not post the hardware itself at this time, is currently not presentable. But some results already appear on the Nextion display.
Last edited by Wiki on 03 Jun 2020, 15:30, edited 1 time in total.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#2 Post by Wiki » 03 Jun 2020, 15:22

Here the very first pictures of the display, much more data and pages to come:

Murphy3.jpg
Murphy3.jpg (99.6 KiB) Viewed 3562 times



Using a MPU6050 I am finally able to level the motorhome form drivers seat by moving the vehicle and / or alter the pressure in the air suspension. Has been in the past sometimes really painful to get the vehicle correctly levelled:
Murphy2.jpg
Murphy2.jpg (97.71 KiB) Viewed 3562 times
Attachments
Murphy1.jpg
Murphy1.jpg (97.49 KiB) Viewed 3534 times
Last edited by Wiki on 04 Jun 2020, 15:56, edited 1 time in total.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#3 Post by Wiki » 04 Jun 2020, 15:34

OK, up to now it wasn't very exciting, easy going because ESPEasy and its sensor connections is really, really, easy, wiring and configuring the sensors to get them run is pretty good documented in the ESPEasy Wiki. To give an idea: the state I reached with my current project, to display some GPS data, speed, trip and temperatures on a display took me - 16 years ago - 1 1/2 year. The ongoing project was put together including the very small coding during 2 days!. That's a difference, I mean.

So, now we are coming to more technical stuff.

Step1: Get the levelling of the Motorhome to have a good night. My purpose: getting an idea of the levelling of the vehicle to assure a good working refridgerator and not rolling out of bed during the night. And this idea I need when I am actually parking the vehicle, sitting on drivers chair. For further modifications the pcbs have to be easily removable, so I decided to choose a strong magnetic fixing.

Hardware needed (sorry, some of the links are outdated but at least may be useful to get an idea):

- GY521 MPU6050 Gyro Sensor
- Wemos D1 mini
- Mini 12v-5v Step Down Power Supply
- A piece of wood as a basis for the Wemos, power supply and sensors, in my case 100x150x8mm
- four holed neodym magnets, ordering them, don't forget to assure that you have fitting screws
- a piece of iron tin, in my casr 120x170x1mm
- hot glue
- a flat, horizontal, hidden area to fasten the sensor plate in the motorhome.


The iron plate is fixed with hot glue onto a flat, almost horizontal surface in the underbed compartment at the farest end of the vehicle. Tipp: before applying the glue, heat up the surface and the iron plate a little bit (ofcourse taking into account the heat resistance of the surface!!), you will get better and more durable results:

Gyro2.jpg
Gyro2.jpg (97.21 KiB) Viewed 3539 times

The four magnets are screwed to the plate:

Gyro1.jpg
Gyro1.jpg (91.78 KiB) Viewed 3539 times

And the plate holding the hot glued pcbs will be in place fixed and horizontal:

Gyro3.jpg
Gyro3.jpg (99.41 KiB) Viewed 3536 times

On the left Wemos D1, top mini step down voltage regulator, right GY521 / MPU6050 sensor - and enough space for more sensors to come.

In the next step I will post my rules calculating a (for me) understandable tilt and explain, how to get them onto the Nextion.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#4 Post by Wiki » 04 Jun 2020, 18:30

Step 2: Putting the readings of the Gyro to Nextion.

At first I am creating two tasks, every needed axis gets one:
Murphy_Gyro3.JPG
Murphy_Gyro3.JPG (41.6 KiB) Viewed 3530 times
Murphy_Gyro4.JPG
Murphy_Gyro4.JPG (44.42 KiB) Viewed 3530 times
Additionally I am creating a dummy device to be able to calculate averages and a dummy device to be able to switch on / off sending the data to Nextion manually. I did this to minimize Wifi traffic during the times the levelling is not needed.
Murphy_Gyro1.JPG
Murphy_Gyro1.JPG (39.24 KiB) Viewed 3530 times
Murphy_Gyro2.JPG
Murphy_Gyro2.JPG (18.97 KiB) Viewed 3530 times
Switching measurement On / Off (resp. sending the data):

Hitting the button "Messung" on the Nextion display (refer picture post #2 in this thread) sends an idx of 100 from Nextion to its attached ESPEasy device and this will fire an event on the device with Gyro attached:

Code: Select all

On Di#idx=100 Do
  SendTo 49,'event,Messung'   //Device #49=Gyro-device
EndOn
On Gyro device the process of sending the data is started / stopped, some colors are set on Nextion (device id=#28):

Code: Select all

On Messung Do
  If [Auto#Messung]=1
    TimerSet,1,0                        //Stop sending process
    TaskValueSet 6,1,0               //Store that sending is stopped
    SendTo 28,'Di,page0.h1.val=100'     //setting slider vertical (tilt front/back) into the middle = Zero-position
    SendTo 28,'Di,page0.h1.pic2=4'       //setting slider button to blue colored
    SendTo 28,'Di,page0.p1.pic=4'         //setting middle mark to blue color
    SendTo 28,'Di,page0.t1.txt="Tilt_längs:Aus"'  
    SendTo 28,'Di,page0.h0.val=100'     //setting slider horizontal (tilt left/right) in the middle = Zero-position
    SendTo 28,'Di,page0.h0.pic2=3'      //setting slider button to blue colored
    SendTo 28,'Di,page0.p0.pic=3'       //setting middle mark to blue color
    SendTo 28,'Di,page0.t0.txt="Tilt_quer:Aus"'
    SendTo 28,'Di,page0.b0.pic=5'      //setting button "Messung" to blue LEDs
Else
    TaskValueSet 6,1,1             //Start sending process
    TimerSet,1,1                      //Store that sending is started
    SendTo 28,'Di,page0.b0.pic=6'      //setting button "Messung" to green LEDs 
    SendTo 28,'Di,page0.h1.pic2=9'     //setting middle mark to green colored
    SendTo 28,'Di,page0.p1.pic=9'      //setting slider button to green colored
    SendTo 28,'Di,page0.h0.pic2=8'    //setting middle mark to green colored 
    SendTo 28,'Di,page0.p0.pic=8'      //setting slider button to green colored
  EndIf
EndOn
On Rules#Timer=1 Do
  TimerSet 1,1
  TaskRun 1     //trigger the correspondig tasks for X / Y-axis
  TaskRun 2
EndOn

On task-triggered events I generate a little bit of averaging to minimize influence of whatever, i.e. egine vibrations and write the results directly on the Nextion screen.

Code: Select all

On X#X Do
  let 4,%v3%
  let 3,%v2%
  let 2,%v1%
  let 1,[X#X]
  TaskValueSet 3,1,(%v1%+%v2%+%v3%+%v4%)/4000*5.625+0.7     //bringing the raw data in somewhat useful format for my eyes and calibrating zero (^= +0.7)
  let 8,([XY#X]*10)+100        //adopting to the middle of the slider in Nextion (°=100)
  If [Auto#Messung]=1         //doublecheck, if sending data is not initiated by the task schedule itself
  SendTo 28,'Di,page0.h1.val=[int#8]'
  SendTo 28,'Di,page0.t1.txt="Tilt_längs:[XY#X]"'
  EndIf
EndOn
On Y#Y Do
  let 12,%v11%
  let 11,%v10%
  let 10,%v9%
  let 9,[Y#Y]
  TaskValueSet 3,2,(%v9%+%v10%+%v11%+%v12%)/4000*5.625-0.4     //bringing the raw data in somewhat useful format for my eyes and calibrating zero (^= -0.4)
  let 16,([XY#Y]*-10)+100        //adopting to the middle of the slider in Nextion (°=100)
  If [Auto#Messung]=1            //doublecheck, if sending data is not initiated by the task schedule itself
    SendTo 28,'Di,page0.h0.val=[int#16]'
    SendTo 28,'Di,page0.t0.txt="Tilt_quer:[XY#Y]"'
  EndIf
EndOn

And here we are, assuming that the Nextion display is placed correctly somewhere reachable and visible by the driver we have a running levelling gauge for our motorhome. That (ESP)Easy(RV)


In the next step I will show, how to get the water level of the tank.


[edit]
Eeehm, I forgot: For calibration of the levelling I took an ordinary bubble level, placed the car in absolute levelled position and added the correspondig values to my rules code (in this case: X-direction: +0.7 and Y-direction: -0.4))
[/edit]
Last edited by Wiki on 07 Jun 2020, 16:23, edited 1 time in total.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#5 Post by Wiki » 07 Jun 2020, 16:10

Next part of the project, water level in frishwater tank.

My motorhome isn't the youngest one and the old system to show the water level inside the freshwater tank has only four leds to show full / medium / low / empty. But if it shows "empty" there is still somewhat of 40 liter of water inside (from a maximum of 100 liter). So I can't name it accurate in any way, its just useless if you want to know if you get the shampoo out of your hair during taking a shower.

What I am presenting now is a good part off topic concerning the forum itself. But to prevent someone others to run into the same mistakes I made, I would like to explain in detail what I did do, perhaps may be useful for others.

My design will be a floater in the tank equipped with a MPU6050 to get the angle of the floater for calculating the water level.

I used (or will use) the following parts:

- a plastic pill bottle, modified to get waterproof, a petling would do a better job I guess, but I didn't want to order 20 pieces to get a reasonable price or to order one for somewhat 8.50€-10€ (as I now know, I should have done that ;-))
- 2x waterproof 4-pole docking plugs to connect cables once inside and once outside of the tank
- 2x M6 Metric Cable Gland Waterproof for 2-4mm cables to get the cable for the sensor through the cap of the floater and through the tank wall
- Some meter of 4 core cable
- some 4 pin connectors
- 0.5mm stainless steel tin and stainless steel 2mm straight welding rod
- 1x Stainles steel lug (mine is a female one)
- O-rings to seal the lug screw
- preferrably a 3D-printer
- ...and, ofcourse, 1x MPU6050 GY521, 1x Wemos D1 mini, 1x ESPEasy

My stupid idea to save money by using a pill bottle for my floater made the highest efforts to get it waterproof. But nevertheless, I show you, which stupidity I did.

My first waterproofing test I did with the unmodified bottle by submerging it for ~5 hours:
floater1.jpg
floater1.jpg (92.22 KiB) Viewed 3428 times
Surprisingly the sealing of the cap was originally made of paper (!), which let the water through after a while. So I replaced it ny cutting out a sealing out of an old bycicle tube. Second submerge test was successful.

I produced an arm for my floater made of stainless steel parts:
floater2.jpg
floater2.jpg (89.03 KiB) Viewed 3428 times
floater3.jpg
floater3.jpg (92.23 KiB) Viewed 3428 times
And did a floating test, which was really promising that it will work:
floater4.jpg
floater4.jpg (95.02 KiB) Viewed 3428 times
And at last I added a cable to my pill bottle, made another sumerging test with it, this time in a depth of 0.5m, which should be enough, which it passed.
floater5.jpg
floater5.jpg (97.37 KiB) Viewed 3428 times
Next step will be the placing of sensor and cables. Due to the fact that the submerging tests and the modifying of the pill bottle took so much time, for me is not left enough day today to continue now. So stay tuned....

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#6 Post by TD-er » 07 Jun 2020, 21:26

Not to discourage your efforts of using a floater.
Have you considered using an ultrasonic distance sensor?
There are also water-proof versions available.

If you considered it, then I do want to know why it was found to be useless.

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#7 Post by Wiki » 08 Jun 2020, 01:07

It could have been so easy, yes. But the tank itself has a height inside of 32 cm. The sensors I've found in the past are beginnig at 300 mm to work, so that would be kind of useless. And don't forget: the moments the water has a calm surface are pretty rare.

Two days ago someone posted here a waterproof ultrasonic sensor, with a minimum working range of 30 mm. That could be my solution in the future, yes. But I am too far with my floater to stop now.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#8 Post by Wiki » 08 Jun 2020, 01:16

Ah, and btw.: I am using an ultrasonic sensor in my cisterne. My experience: a Spider on the sensor or a.drop of condensed water make it useless. Not so important in my cisterne, somewhen the spider would walk away and the drop of water will be vaporized. But in a height of 32 cm for 100 l of water misreadings caused by a waterdrop could be catastrophic for the shampoo in your hair.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#9 Post by TD-er » 08 Jun 2020, 08:53

Wiki wrote:
08 Jun 2020, 01:16
[...] But in a height of 32 cm for 100 l of water misreadings caused by a waterdrop could be catastrophic for the shampoo in your hair.
Yep, those are killing for the WAF.

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#10 Post by TD-er » 08 Jun 2020, 20:19

Jimmy sent me this sensor link for a liquid level sensor: https://a.aliexpress.com/_dWTFi8A

It isn't a cheap one and I don't know the measuring principle.
But it is available for several ranges in liquid levels, the lowest being 0 - 1m.
It looks like it outputs an analog value, analogue (pun intended) to the water level I assume.

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#11 Post by Wiki » 09 Jun 2020, 04:01

Thank you, but my first floater tests are surprisingly good. In a 15 l bowl today I was able to estimate the water level in a range of 1cm. For a motorhome user thats a spot landing. Never forget:We are talking about a vehicle, which is constantly in movement, at least by the movement of persons inside of it, except you have a luxury one which is levelled and fixed by hydraulic aids.

Believe me, a floater is a good and reasonable solution. And if you still have any doubts: why, do you hink, the gasoline tank of your car still is equipped with a floating sensor to give you an idea, when to approach a gasoline station?

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#12 Post by TD-er » 09 Jun 2020, 09:17

I do know the floater concept is used for ages and works reliable.
If you can mount the floater reliable to whatever you use to determine its angle (e.g. potmeter) then it is for sure the preferred solution.
It probably does give a lot more 'filtered' output compared to measuring a single spot.

My only worry was that it may need more modifications compared to a smaller sensor.

HomeJCL
Normal user
Posts: 74
Joined: 03 Feb 2018, 10:42

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#13 Post by HomeJCL » 09 Jun 2020, 13:25

TD-er wrote:
08 Jun 2020, 20:19
Jimmy sent me this sensor link for a liquid level sensor: https://a.aliexpress.com/_dWTFi8A

It looks like it outputs an analog value, analogue (pun intended) to the water level I assume.
That is a hydrostatic measurement or a pressure transmitter.

As for thé float, on a long stick, you will need to think about slushing in the tank, water bar is incredible in what it can do.

Something like this https://www.aliexpress.com/item/329342 ... web201603_is better suited, can also be built in a stilling well
Belgium and land of ESP ... counting :D

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#14 Post by Wiki » 09 Jun 2020, 15:48

HomeJCL wrote:
09 Jun 2020, 13:25
[...}
As for thé float, on a long stick, you will need to think about slushing in the tank, water bar is incredible in what it can do.
[...]
Thats exactly what I am still worried about, fast moving water has incredible forces. And thats why I didn't trust a waterproofing only by floating on the surface but submerged the floater. I would trust my design much more if I could give some pressure (somewhat like 1.5-2 bar) on the submerged floater, but I don't have the equipment for doing this. I had a BME280 at hand and have added it to the sledge the sensor is sitting on to be alarmed if the humidity inside rises. And yes, I know that there are better solutions for leakage alarms, but the BME has been laying around.
Sledg1.jpg
Sledg1.jpg (17.83 KiB) Viewed 3298 times
Sledg2.jpg
Sledg2.jpg (10.75 KiB) Viewed 3298 times
And I will put a handful small, fast fuses into the wiring....and additionally I will use a condom :D

During the measurement test yesterday I noticed that the ring for holding the stick is not the best solution. Theres a danger that it could get stuck. So I will have to alter the design anyway and I will put the floater into the middle of the tanks heighth so I could cut the length of the stick, thanks for your suggestions.
HomeJCL wrote:
09 Jun 2020, 13:25
[...]
Something like this https://www.aliexpress.com/item/329342 ... web201603_is better suited, can also be built in a stilling well
No, its not better suited, its the PERFECT SOLUTION. I will contact the seller, he says he could deliver different sizes. Thanks a lot for the link and I am glad to have put my little project over here. And Thanks @TD-er and @grovkillen for their thoughts, too.

Nevertheless, because I have to drill into the tank anyway and I need a solution right next week I will give the floater a try. Its almost ready to do so and to be frankly, I am pretty curious if it would work.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

HomeJCL
Normal user
Posts: 74
Joined: 03 Feb 2018, 10:42

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#15 Post by HomeJCL » 09 Jun 2020, 17:26

Pressure testing the simplest https://www.youtube.com/watch?v=qBZbLdotrG0 but with a bigger jam jar and get inspiration from the next one, can have a nice setup.
Although with jam jar don’t overcook it on the pressure !!!

More sophisticated https://www.christopherwardforum.com/v ... 33&t=10816

Have a soft spot for watches :D
Belgium and land of ESP ... counting :D

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#16 Post by Wiki » 12 Jun 2020, 02:37

OK, next step is done.

This "thing" went inside my freshwater tank after being - more or less accurate - calibrated last night by using a bowl and some liters of water:

Floater1.1.jpg
Floater1.1.jpg (85.88 KiB) Viewed 3185 times

Now its inside of the tank and I will show you, why I did these efforts (despite the fact that with some more research probably it could have been easier). The next picture shows the reading of the onboard water level info:

Floater1.2.jpg
Floater1.2.jpg (94.81 KiB) Viewed 3185 times

Its says, the tank is almost empty and at this moment - if I should trust the LEDs - it would be risky to take a shower. But I filled the tank already with 45 liters of water - almost the half of its volume of 100 liters. The reading of my floater/sensor combination tells me:

Floater1.3.jpg
Floater1.3.jpg (93.77 KiB) Viewed 3185 times

The difference to the amount of water I filled into the tank is easy to explain: its the weight of the floater. So the weight eats up some 7-9l of water before the floater begins to float. At least this is acceptable, the gasolin gauge in your car behaves the same way.

Lets leave the handcraft part and return to ESPEasy. The device is configured:
Floater1.4.JPG
Floater1.4.JPG (29.8 KiB) Viewed 3185 times
And a dummy device for storing values neede for calculation:
Floater1.5.JPG
Floater1.5.JPG (24.88 KiB) Viewed 3185 times
The way the end of the floater rises is a direct linear function to the read acceleration of the sensor. So the height of the floater above the tanks bottom can be calculated directly by the factor length floater/16384 (max reading of the MPU6050 +/- direction). Depending on the floater angle in relation to the surface of the water (optimum would be a ball, my floater is a cylinder) the factor varies a little bit over the height, I took an estimated average of this factor. To minimize the influence of water movement I am averaging the raw readings to the maximum I can using ESPEasy, might be possible to reduce it.

Code: Select all

On X#X Do
  let 15, %v14%
  let 14,%v13%
  let 13,%v12%
  let 12,%v11%
  let 11,%v10%
  let 10,%v9%
  let 9,%v8%
  let 8,%v7%
  let 7,%v6%
  let 6,%v5%
  let 5,%v4%
  let 4,%v3%
  let 3,%v2%
  let 2,%v1%
  let 1,[X#X]
let 16,(%v1%+%v2%+%v3%+%v4%+%v5%+%v6%+%v7%+%v8%+%v9%+%v10%+%v11%+%v12%+%v13%+%v14%+%v15%)/15 //averaging
TaskValueSet,4,1,%v16%
let 16,292-[test#dummy]*-0.021 // 292 = lenght of the floater minus height of mounting point, 0.021 = tan-constant calculated from max to actual accreleration
taskvalueset,4,2,%v16%
let 16,[int#16]*450*680/1000000  // depending on the size of the tank calculation of volume
TaskValueSet,4,3,%v16%
SendTo 28,'Di,page3.t2.txt="Stand:[int#16]l"'   //and send the whole stuff to the Nextion device
SendTo 28,'Di,page3.j0.val=[int#16]'
SendTo 28,'Di,page3.t3.txt="[Temp#C]°C"'
SendTo 28,'Di,page3.t4.txt="[Temp#H]%"'
SendTo 28,'Di,page3.t5.txt="[Temp#P]hPa"'
EndOn

...and again, thats all. I got a perfect information of my oboard water. Only thing is: up to now, the vehicle itself wasn't moved. Wether my design is standing the rough environment of a moving home the future wil tell me. Thanks to ESPEasy, its mighty sensor connection posibilities in combination with rules.

In this case, handcrafts took around two days, attaching and configuring the sensors, adding the rules was done almost in minutes.

In the next step I will present a trip/ travel tracker.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#17 Post by Wiki » 12 Jun 2020, 03:06

I forogot - as always - two things:

1. the readings of the water level has - between ~8l and 95l - an accuracy of 1 liter, in a tank of 32 cm of height
2. the levelling system I described before is that sensible, that it told me after filling 50 liters of water into the tank (this is placed in the left side of the vehicle), that the vehicle should be levelled once again - and the RV itself has a gross weight of almost 3.000 kg.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#18 Post by TD-er » 13 Jun 2020, 11:22

I was thinking... you could also place weight sensors under the tank.
Not sure what range of those you should use, as I can imagine a moving tank of water may give quite a strong impact force every now and then.

Not that you should change it now, but just theoretically, could it be done?

If you place those sensors at each corner, maybe the water tank can then also be used to measure how level the vehicle is.

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#19 Post by Wiki » 13 Jun 2020, 13:29

The tank with its (on the road heavily slushing) mass has to be fixed as tight as possible. No way to use these kind of sensors.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

User avatar
ManS-H
Normal user
Posts: 237
Joined: 27 Dec 2015, 11:26
Location: the Netherlands

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#20 Post by ManS-H » 13 Jun 2020, 15:51

Wiki wrote:
13 Jun 2020, 13:29
The tank with its (on the road heavily slushing) mass has to be fixed as tight as possible. No way to use these kind of sensors.
You can use a flowmeter and count what you use.
Another possibility is descripe here: https://www.camperforum.nl/viewtopic.php?t=8457836

Its in Dutch, so you need Google Translate.

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#21 Post by Wiki » 13 Jun 2020, 16:35

ManS-H wrote:
13 Jun 2020, 15:51
[...]
You can use a flowmeter and count what you use.
[...]
Yes, ofcourse. But how do I get the current amount of water when filling the tank only partly? I have been at many places where I get the water not directly but have to carry it in a jerry can. And believe me, pouring rain and 250m to walk forces you to minimize the momentary efforts.

A hydraulic pressure sensor is useable, yes. But it seems as if am fine with my floater. I am pretty sure that I have to change this or that, that's why I have built this guy detechable. But the principle is pretty accurate as I know now. The lack of the last 8 liters isn't important, the display will show "<10l" (you won't be able to take a shower with less than 10l of water), the maximum level isn't important either, it will show ">95l". And don't forget: total amount of spent money less than 5€. Beat it.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#22 Post by Wiki » 13 Jun 2020, 18:46

First test. I had to make a trip of 20km, lot of corners, breaking, accelerating, 70 liters of water onboard to have a rough environment for the floater.

Everything stayed in its place, readings of waterlevel during driving are useable to make a decision if our next place we are heading for has to have the possibility of tanking water or not. The level was displayed in a range of +/- 5l. So I can tell, the design is worth the efforts I had.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#23 Post by TD-er » 13 Jun 2020, 18:59

And the logged trip distance? :)

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#24 Post by Wiki » 13 Jun 2020, 22:22

I could send you the complete trip in 100m steps geo data as an excel sheet.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#25 Post by TD-er » 13 Jun 2020, 22:30

Wiki wrote:
13 Jun 2020, 22:22
I could send you the complete trip in 100m steps geo data as an excel sheet.
Was mainly asking to know if the reported distance was similar to the trip counter of the car

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#26 Post by Wiki » 14 Jun 2020, 02:48

Yes, Sir, it was as accurate as I already posted, -~1-2%.

And have a look, using the experimental cache controller, your html-based GPS2csv converter and converting the data to gpx file, importng this to an online OMS-GPX viewer the result looks like this one (I removed the underlaying map):
GPS.JPG
GPS.JPG (15.26 KiB) Viewed 3031 times
In the next step I will explain in detail what I have done how.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#27 Post by TD-er » 14 Jun 2020, 11:18

Yep that cache controller works very well :)
I've been using it myself for over a year in several units now.

I will also test it on LittleFS to see how that performs as you then may be able to record a lot more samples on 16M nodes :)

The offset from the trip meter in the dashboard of your car may also be off due to differences in tires etc.
I always wondered if the speed meter and the trip meter were in sync, as I have an offset of roughly 8% with the GPS speed. (reported speed is too high)
I guess it makes no sense to have them out of sync, but that the manufacturers would not dare to show a speed which is possibly lower than the actual speed as that may lead to law suits.
For example my offset in reported speed differs between summer and winter tires. But maybe that can also be related to the fact the garage makes sure the tires they put on are at the right pressure and after half a year driving the just removed ones may not be anymore.

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#28 Post by Wiki » 14 Jun 2020, 15:50

OK, here we go, next step of my tiny project: Trip recorder.

You need:

- a GPS device, mine is a Neo6M, others are supported, too. I tok the Neo6M because I ave positive experiences in other automotive projects. Supported devices are documented in the ESPEasy readthedocs
- a Wemos D1
- another Wemos D1 and the Nextio display
- In my case ESP_Easy_mega_20200608_custom_ESP8266_4M2M.bin to get the cache controller and some more space to store data

On the road I get the current GPS readings including some calculated values:
GPS6.JPG
GPS6.JPG (88.3 KiB) Viewed 2976 times
The fields names are self explaining.

Using the last custom build

Code: Select all

ESP_Easy_mega_20200608_custom_ESP8266_4M2M
ESPEasy gives me the experimental cache controller which is able to write some data into the flash:
GPS3.JPG
GPS3.JPG (58.19 KiB) Viewed 2976 times
Defining some devices:
GPS2.JPG
GPS2.JPG (98.26 KiB) Viewed 2976 times
GPS4.JPG
GPS4.JPG (68.22 KiB) Viewed 2976 times
GPS5.JPG
GPS5.JPG (79.34 KiB) Viewed 2976 times
GPS7.JPG
GPS7.JPG (77.59 KiB) Viewed 2976 times
is the prerequisit for what I am doing now.

Since the last release the GPS plugin sends an event depending on the travelled distance including the calculated distance since last event. I take this value to add it to the total distance travelled, write it into the dummy device and send the values to the cache controller which writes it into the flash:

Code: Select all

On GPS#travelled Do
  if %eventvalue%<500   //just make sure there's no misreading of the GPS sensor
  let 1,[Strecke#Strecke]+%eventvalue%  //adding the distance
  TaskValueSet 2,1,%v1%  //setting dummy values
  TaskValueSet 2,2,[GPS#lat]
  TaskValueSet 2,3,[GPS#long]
  TaskValueSet 2,4,[GPS#alt]
  TaskRun 2  //run the task to write the data into the flash using the cache controller
  let 1,[GPS#spd]*3.6   /calculating speed in km/h
  SendTo 28,'Di,page2.t7.txt="[int#1]km/h"'
  SendTo 28,'Di,page2.t1.txt="Long:[GPS#long]°"'
  SendTo 28,'Di,page2.t2.txt="Lat:[GPS#lat]°"'
  let 1,[GPS#alt]
  SendTo 28,'Di,page2.t3.txt="Höhe:[int#1]m"'
  SendTo 28,'Di,page2.t4.txt="Speed:[GPS#spd]m/s"'
  let 1,[Strecke#Strecke]/1000
  SendTo 28,'Di,page2.t5.txt="Trip:%v1%km"'   //displaying the total distance since last trip reset
  EndIf
EndOn
Hitting the "Trip Reset" button on the display generates an event on the device to reset trip time as well as trip distance:

Code: Select all

On TripReset Do
  SendTo 28,'Di,page2.t5.txt="Trip:0.0km"'
  SendTo 28,'Di,page2.t7.txt="0km/h"'
  TaskValueSet 2,1,0
  TaskValueSet 3,1,%uptime%
  TaskValueSet 3,2,0
  SendTo 28,'Di,page2.t6.txt="Zeit:%c_m2dhm%([Strecke1#Tripzeit])"'
  TaskValueSet 2,2,[GPS#lat]
  TaskValueSet 2,3,[GPS#long]
  TaskValueSet 2,4,[GPS#alt]
  TaskRun 2
EndOn
For calculating the trip time since last trip reset I am using the uptime of the device, calculating the difference betwen starttime and current uptime, writing it into the dummy variable and send it every minute to the Nextion display:

Code: Select all

On Clock#Time=All,**:** Do
  SendTo 28,'Di,page1.t10.txt="%systm_hm%"'  //sending the GPS-depending time to the zime fields of the various Nextion pages
  SendTo 28,'Di,page2.t10.txt="%systm_hm%"'
  SendTo 28,'Di,page3.t1.txt="%systm_hm%"'
  let 1,%uptime%-[Strecke1#Startzeit]  // calculating the trip time
  TaskValueSet 3,2,%v1%  //setting the dummy value
  SendTo 28,'Di,page2.t6.txt="Zeit:%c_m2dhm%([Strecke1#Tripzeit])"'  //and sending it to Nextion display
EndOn
Some more lines of code make the life easier. Because I am working with testing and experimental parts of ESPEasy some reboot are most likely. The values of the dummy devices will survive a reboot, but the uptime will be reset to zero. So I want to assure the surviving of the trip time:

Code: Select all

On System#Boot Do
//Warmstart überleben Tripzeit
  let 1,0-[Strecke1#Tripzeit]
  TaskValueSet 3,1,%v1%
  TaskValueSet 3,2,0
EndOn
The Nextion will not run 24/7 so it is useful to inform the GPS device that the Nextion display has been started. On System#Boot the Nextion device generates an event on the GPS device which will send the currrent display data:

Code: Select all

On NextionInit Do
  let 1,[GPS#spd]*3.6
  SendTo 28,'Di,page2.t7.txt="[int#1]km/h"'
  SendTo 28,'Di,page2.t1.txt="Long:[GPS#long]°"'
  SendTo 28,'Di,page2.t2.txt="Lat:[GPS#lat]°"'
  let 1,[GPS#alt]
  SendTo 28,'Di,page2.t3.txt="Höhe:[int#1]m"'
  SendTo 28,'Di,page2.t4.txt="Speed:[GPS#spd]m/s"'
  let 1,[Strecke#Strecke]/1000
  SendTo 28,'Di,page2.t5.txt="Trip:%v1%km"'
EndOn
So whatfor am I doing all this stuff except for online information during driving?

@TD-er was so kind topost:

TD-er wrote:
30 May 2020, 09:48
[...]
On the file system I have placed this .htm file (use .htm as extension, not .html)
Via the browser you can then open this .htm file and export all recorded samples to a .csv file
A stored task takes 24 bytes, so storing 2 dummy tasks like this takes 48 bytes per interval.
On a build with 4M flash divided in 1M filesystem, you can store roughly 750k of files.

Code: Select all


<html>
<script src="https://cdn.jsdelivr.net/npm/lodash@4.17.11/lodash.min.js"></script>
<script>
const TASKS_MAX = 12;
const VARS_PER_TASK = 4;

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

class DataParser {
    constructor(data) {
        this.view = new DataView(data);
        this.offset = 0;
        this.bitbyte = 0;
        this.bitbytepos = 7;
    }

    pad(nr) {
        while (this.offset % nr) {
            this.offset++;
        }
    }

    bit(signed = false, write = false, val) {
        if (this.bitbytepos === 7) {
            if (!write) {
                this.bitbyte = this.byte();
                this.bitbytepos = 0;
            } else {
                this.byte(signed, write, this.bitbyte);
            }
        }
        if (!write) {
            return (this.bitbyte >> this.bitbytepos++) & 1;
        } else {
            this.bitbyte = val ? (this.bitbyte | (1 << this.bitbytepos++)) : (this.bitbyte & ~(1 << this.bitbytepos++));
        }
    }

    byte(signed = false, write = false, val) {
        this.pad(1);
        const fn = `${write ? 'set' : 'get'}${signed ? 'Int8' : 'Uint8'}`;
        const res = this.view[fn](this.offset, val);
        this.offset += 1;
        return res;
    }

    int16(signed = false, write = false, val) {
        this.pad(2);
        let fn = signed ? 'Int16' : 'Uint16';
        const res =  write ? this.view[`set${fn}`](this.offset, val, true) : this.view[`get${fn}`](this.offset, true);
        this.offset += 2;
        return res;
    }

    int32(signed = false, write = false, val) {
        this.pad(4);
        let fn = signed ? 'Int32' : 'Uint32';
        const res =  write ? this.view[`set${fn}`](this.offset, val, true) : this.view[`get${fn}`](this.offset, true);
        this.offset += 4;
        return res;
    }
    float(signed = false, write = false, val) {
        this.pad(4);
        const res =  write ? this.view.setFloat32(this.offset, val, true) : this.view.getFloat32(this.offset, true);
        this.offset += 4;
        return res;
    }
    bytes(nr, signed = false, write = false, vals) {
        const res = [];
        for (var x = 0; x < nr; x++) {
            res.push(this.byte(signed, write, vals ? vals[x] : null));
        }
        return res;
    }
    ints(nr, signed = false, write = false, vals) {
        const res = [];
        for (var x = 0; x < nr; x++) {
            res.push(this.int16(signed, write, vals ? vals[x] : null));
        }
        return res;
    }
    longs(nr, signed = false, write = false, vals) {
        const res = [];
        for (var x = 0; x < nr; x++) {
            res.push(this.int32(signed, write, vals ? vals[x] : null));
        }
        return res;
    }
    floats(nr, signed = false, write = false, vals) {
        const res = [];
        for (var x = 0; x < nr; x++) {
            res.push(this.float(write, vals ? vals[x] : null));
        }
        return res;
    }
    string(nr, signed = false, write = false, val) {
        if (write) {
            for (var i = 0; i < nr; ++i) {
                var code = val.charCodeAt(i) || '\0';
                this.byte(false, true, code);
            }
        } else {
            const res = this.bytes(nr);
            return String.fromCharCode.apply(null, res).replace(/\x00/g, '');
        }
    }
}

const parseConfig = (data, config, start) => {
    const p = new DataParser(data);
    if (start) p.offset = start;
    const result = {};
    config.map(value => {
        const prop = value.length ? value.length : value.signed;
        _.set(result, value.prop, p[value.type](prop, value.signed));
    });
    return result;
}
/*
const fileFormat = [
    [...Array(1000)].map((x, i) => ({ prop: `samples[${i}].values`, type:'floats', length: VARS_PER_TASK  })),
    [...Array(1000)].map((x, i) => ({ prop: `samples[${i}].timestamp`, type: 'longs', signed: false  })),
    [...Array(1000)].map((x, i) => ({ prop: `samples[${i}].controllerIndex`, type: 'byte'  })),
    [...Array(1000)].map((x, i) => ({ prop: `samples[${i}].taskIndex`, type: 'byte'  })),
    [...Array(1000)].map((x, i) => ({ prop: `samples[${i}].sensorType`, type: 'byte'  })),
    [...Array(1000)].map((x, i) => ({ prop: `samples[${i}].valueCount`, type: 'byte'  })),
];
*/
const fileFormat = [
    { prop: 'values', type:'floats', length: VARS_PER_TASK },
    { prop: 'timestamp', type: 'int32', signed: false },
    { prop: 'controllerIndex', type: 'byte' },
    { prop: 'taskIndex', type: 'byte' },
    { prop: 'sensorType', type: 'byte' },
    { prop: 'valueCount', type: 'byte' },
];

/*
loadConfig = () => {
    return fetch('http://192.168.1.182/cache_json').then(response => response.arrayBuffer()).then(async response => {
        document.body.innerText = parseConfig(response, fileFormat);
    });
}
*/

loadConfig = async () => {
    const floatvalues = {};
    const info = await fetch('/cache_json').then(response => response.json());
	let csv = info.columns.join(';') + '\n';
	for (var j = 0; j < (VARS_PER_TASK * TASKS_MAX); j++) {
		// TODO make "unused" value configurable
		floatvalues[j] = 0;
	}
	
	// TODO must also read partial files (< 24k)
	var maxFileNr = info.files.length;
	for (var filenr = 0; filenr < maxFileNr; filenr++) {
	    var elem = document.getElementById("bar");
		var width = Math.round(100.0 * (filenr / (maxFileNr - 1 )));
		elem.style.width = width + '%'; 
        elem.innerHTML = width * 1 + '%';
		const binary = await fetch(info.files[filenr]).then(response => response.arrayBuffer()).then(async response => { 
			const samples = {};
			var arrayLength = response.byteLength / 24;
			//1000;//samples.length;
			
			[...Array(arrayLength)].map((x, i) => {
				samples[i] = parseConfig(response, fileFormat, 24 * i);
			});
			
			// TODO Fetch number of samples.
			for (var i = 0; i < arrayLength; i++) {
			  var floatIndex = VARS_PER_TASK * samples[i].taskIndex;
			  samples[i].values.forEach(item => {
				floatvalues[floatIndex] = item;
				floatIndex++;		  
			  });
			  // TODO quick fix to remove damaged samples due to writing to closed files.
			  if (samples[i].timestamp > 1500000000) {
			      const utc_date = new Date(samples[i].timestamp * 1000);
				  csv += samples[i].timestamp + ';' + utc_date.toISOString() + ';' + samples[i].taskIndex;
				  for (var j = 0; j < (VARS_PER_TASK * TASKS_MAX); j++) {
					csv += ';' + floatvalues[j];
				  }
				  csv += '\n';  
			  }
			}
			await sleep(100); // Wait to prevent the ESPeasy node from rebooting.			
		});
	}
//	document.body.innerText = csv;
//    document.body.innerHTML = `<a href='data:text/plain;charset=utf-8,${encodeURIComponent(csv)}' download='test.csv'>click me</a>`;

	const a = document.createElement('a');
	const aText = document.createTextNode('Download');
	a.href = window.URL.createObjectURL(new Blob([csv]), {type: 'text/csv'});
	a.download = 'test.csv';
	a.appendChild(aText);
	a.classList.add("button");
	document.getElementById("downloadLink").appendChild(a);
//	document.body.appendChild(a);
}
</script>

<style>
#progress {
  width: 100%;
  background-color: #ddd;
}

#bar {
  width: 0%;
  height: 30px;
  background-color: #4CAF50;
  text-align: center;
  line-height: 30px;
  color: white;
}

h1, h2 {
    font-size: 16pt;
    margin: 8px 0;
}

h1, h2 {
    color: #07D;
}

* {
    box-sizing: border-box;
    font-family: sans-serif;
    font-size: 12pt;
    margin: 0;
    padding: 0;
}

.button {
    background-color: #07D;
    border: none;
    border-radius: 4px;
    color: #FFF;
    margin: 4px;
    padding: 4px 16px;
}

</style>
<body>

<h2>ESPeasy cache to CSV</h2>
<BR>

<button class="button" type="button" onclick="loadConfig()">Fetch cache files</button>

<div id="progress">
  <div id="bar">0%</div>
</div>
<BR>
<p id="downloadLink"></p>
</body>
</html>
Using the cache controller and the html-code I get a semicolon seperated .csv file which - with a little bit of work - I can convert them to a .gpx format using GPSBabel.

At first I have to cleanup the data extracted from the devices flash using the html-code of @TD-er, I am doing this using Excel. You have to assure, that the excel-produced "," inside the exported .csv have are converted to ".". I am doing this currently simply using wordpad. Works. Up to now I was concentrated purely on the geodata Latitude and Longitude, much more is possible. Out of the .csv file I build a tab-delimited file with a header setting, structure looks like this:

Code: Select all

No	Latitude	Longitude
0	xx.xxxxxxx	y.yyyyyyyyy
.
.
.
.
.
This structure can be imported by GPSBabel using the universal csv format:
GPS8.JPG
GPS8.JPG (92.06 KiB) Viewed 2976 times
Last edited by Wiki on 15 Jun 2020, 13:00, edited 2 times in total.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#29 Post by Wiki » 14 Jun 2020, 16:05

Taking the produced .gpx file onto the page https://www.bernhard-gaul.de/gpxviewer/gpxviewer.php you will get as a result your travelled road track:
GPS.JPG
GPS.JPG (15.26 KiB) Viewed 2973 times
I did remove the underlaying map, but if you do it by yourself, you will have a wonderful mapview of your travel.

The map with the track on it clarifies, why the traced distance using GSP plugin will never be able to get the 100% accurate reading. Corners are looking like this:
GPS1.JPG
GPS1.JPG (74.81 KiB) Viewed 2973 times
Thats because the distance is calculated between the current and the last geo position. This calculation will be a straight line, so the corners are partially cut. But the total difference for me personally is absolute neglectible. E.g. on a trip of around 30km the odomoter reading of the car differed less than 100m to the reading of the trip counter. The readings of my system will be more accurate in the future, because with the latest release I get the calculated distance pretty accurate. So I will reduce the "Distance Update Interval" to somewhat like 25 or 30m. We will see.

Summed up: the whole system is built up with a handful lines of code in the rules. Thats all, Thanks to ESPEasy, its mighty sensor connection and the underlaying code of the developers.

[edit]
Spent money: less than 11€. Beat it.
[/edit]

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#30 Post by Wiki » 14 Jun 2020, 17:04

And, please:

If someone uses the free services and tools I linked in my posts, don't forget to donate the developers of these tools. Its worth it and I am pretty sure that they have had a lot of work and costs to develop and present the tools and functions.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#31 Post by Wiki » 15 Jun 2020, 13:02

To get a clear starting point of my travel I have added four lines to the rule for Tripreset on the GPS device, modified the original post, too:

Code: Select all

On TripReset Do
  SendTo 28,'Di,page2.t5.txt="Trip:0.0km"'
  SendTo 28,'Di,page2.t7.txt="0km/h"'
  TaskValueSet 2,1,0
  TaskValueSet 3,1,%uptime%
  TaskValueSet 3,2,0
  SendTo 28,'Di,page2.t6.txt="Zeit:%c_m2dhm%([Strecke1#Tripzeit])"'
  TaskValueSet 2,2,[GPS#lat]
  TaskValueSet 2,3,[GPS#long]
  TaskValueSet 2,4,[GPS#alt]
  TaskRun 2
EndOn

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#32 Post by TD-er » 15 Jun 2020, 13:25

Since we're checking the distance on every position update anyway, I could keep track of it in a counter.
This way you could get an accuracy based on updates roughly 3 times a second.
But I think this may also introduce an error which will be reporting a longer distance then actually traveled as you may then measure a saw-tooth pattern with HDOP as some sort of amplitude.
For slow speed movements this may attribute to quite some error.

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#33 Post by Wiki » 15 Jun 2020, 14:16

Well, I think lowering the update interval may help. In the past, using my old system, I made the experience that constantly counting leads to differences, too. Calculating the distance as it is now implemented makes imho more sense, because its a kind of averaging and reduces errors due to time shifts which take place in the GPS system itself, highly depending on the quality of used hardware. Take a good chip like the Neo 6M and put a bad antenna on it - results will be quite suprising.

Today I have to be on the road anyway and I redu ed the update interval to (I think) 40 m. I will report.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#34 Post by Wiki » 15 Jun 2020, 14:34

And have in mind, that the odometer of a vehicle may have a tolerance of upt to 10%. Already changing winter/summer tyres leads to differences due to different diameters as well as replacing old tyres by new ones, so its only a rough estimation of speed an distance though.

Today I will have a look at my old system which is still in place and will calculate the distance using google maps for comparism. And I am pretty sure, that your routines give better results, at least compared with my old system. Additionally I will use my app for tracking bycicle trips. So today in the evening we will get some more stuff to discuss.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#35 Post by Wiki » 15 Jun 2020, 17:35

OK, trip done.

Google maps calculation: 15.8km, odometer reading: 15.4km, trip recorder: 15.79km. Trip profile: 10% in village, 90% highway / overland. Difference odometer reading <-> trip recorder/google -2.5%

My app Eco biker completly useless, recorded 3.4km overall. Surprise: the GPS-mouse of my old system has exhaled today the holy breath of electronics and quitted working after 15 years - what a mess concerning the old system but how lucky am I that I did setup the new system ontime. Gotcha!

The distance update interval I had set to 50m. The track on a map looks like this:
GPS9.JPG
GPS9.JPG (32.12 KiB) Viewed 2880 times
You can see, the track is much closer to the (edged,too) map drawing.

Failure discussion:
- The distance reading of the ESPEasy trip recorder works pretty well.
- This time the odometer was wrong. Explanation could be: The high amount of highway influences the odometer reading because the tyre diameter rises with higher speed and thus counts less distance.

I added time and altitude information to the modified file for GPSBabel and - what a surprise, uploading it to the GPX-Viewer I get a whole profile of the trip:
GPS10.JPG
GPS10.JPG (72.63 KiB) Viewed 2880 times
Isn't it nice?

Structure of the data for GPSBabel:

Code: Select all

Time				Latitude	Longitude	Altitude
2020-06-15T13:02:41.000Z	xx.xxxxxxx	y.yyyyyyyy	91.09999847
2020-06-15T13:04:00.000Z	xx.xxxxxxx	y.yyyyyyy	93.1999969
Ok, with this test the part of trip recorder is closed for me, I'm fine and done.

Next step will be to move the battery monitoring from the old system (this part is still working) to my small project. To do this, I have to rebuild the wiring of the batteries, because I am planning to measure the batteries using an INA219. The old system measures the current betwenn batteries and ground, the INA219 needs a modification because this sensor is measuring the high side nof the batterie. Rewiring of the batteries will take a moment, the wires are a little bit stiffer than the wires used for the electronics......So stay tuned.

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#36 Post by TD-er » 15 Jun 2020, 20:42

That's a nice chart of the altitude.
Would be completely useless here in the Netherlands though :)
From here to Groningen (10 km away), I would measure an altitude difference of 10 meters. (including viaducts)

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#37 Post by Wiki » 15 Jun 2020, 22:22

Please stay honest. On a chart like this one it would look like you have mountains over there. Nice, new view....

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#38 Post by TD-er » 15 Jun 2020, 22:30

Sure and very steep hills too... caused by the discrete steps of the altitude resolution of our measurements :)

On the other hand, from my desk I can see a nice building 10 km away.

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#39 Post by Wiki » 15 Jun 2020, 23:37

Next steps planned:

- at first reunion of three test devices to one in production - no further documentation neccessary, question of wiring and cut/paste of rules / configs
- determination of the elevation of the satellite dish
- getting the actual pressure of the air suspension including alarm when travelling with too low pressure (forgotten action after being parked
- probably automatic levelling - depends on the availability of a whereever fitting compressor
- onboard battery monitoring
- solar power monitoring
- sewage tank monitoring
- LPG tank monitoring
- freeze alarm for fresh and sewage water including automatic dump of fresh water tank and tubings and automatic heating of sewage tank
- mobility of the Nextion device inside / outside the vehicle using QI and battery/powerbank

There will appear more options to make the travelling more comfortable, the list might stay growing, so the list isn't complete yet - and I think never will be

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#40 Post by TD-er » 15 Jun 2020, 23:43

Just as a seed to let it grow in your grey matter...
These all don't have to be on the same ESP node to interact with each other :)

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#41 Post by Wiki » 16 Jun 2020, 01:23

Oh, I'm awfully sorry. What I didn't point out in this thread is one outstanding feature of ESPEasy which I am using right now and on which my preliminary thoughts were based on:

The devices are able to interact with eachother only by using the unique device id. Currently I have four devices running in my RV: One for the Nextion display, one for inner temperature and levelling, one for the tank level and one for the GPS data. I don't have to take care about IP adresses, I am sending the informations between the devices just by using the devices ids. This makes life pretty easy if you have to switch between different networks. In my case the mobile network onboard the RV and my network at home. If they are in the same network, they'll find each other. Thats a feature I havn't seen anywhere, except ESPEasy.

Believe me, my complete design is based on this feature. I am very grateful to be able to use this like I already do. I will be able to concentrate the momentary data collection into one device for the sensors and one device for the GUI - the Nextion display, yes. But overall there have to be some more nodes - at least to minimize cable routings inside of the vehicle (12V->5V I get almost everywhere, but data connection using cables??) and to the limited features of the sensors itselves concerning e.g. I²C adressing, use of GPIO ports aso. Even the ESP32 won't help.

I may be known as someone who wants to limit power consumption as low as possible - just have a look at different posts of mine here in the forum. But in this case: my old installation draws about 400mA 24/7 without backlighting the display, the four devices I am using now (except the Nextion display) summarized 160mA. So there's a lot of air to play with...

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#42 Post by TD-er » 16 Jun 2020, 08:54

Ah great.
Well there are new features coming for the peer-2-peer communication. Even without the need for WiFi, but all the rest it will be the same functionality and more :)

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#43 Post by Wiki » 16 Jun 2020, 21:50

Sooooo, first real RV trip.

Intermediate result


Navigation using google maps on an Android 9.0 smartphone
Calculated distance to target: 239 km
Trip reading of vehicles odometer: 234.2 km - aha
Total reading of ESPEasy-RV tripcounter: 238.87 km - perfect
Speed readings of ESPEasy-RV : The whole trip the app Google Maps and the tripcounter of ESPEasy-RV where in perfect synchronization, now and then 1km/h difference, but the other device always reported some seconds later the same value - perfect

@TD-er: you have done an absolute perfect work in an unbeatable time - Thank you, I'll buy you a beer

Levelling the vehicle using ESPEasy-RV levelling meter: Took around 60 secs. to get the RV in perfect level by moving forward/backward and at least lowering the pressure of the air suspension on one side a little bit - perfect
ESPEasy-RV water tank levelmeter: During the whole trip in movement reported values +/- 5l of the real amount of water, from the moment of parking and switching off the engine took 60 secs. to deliver the correct reading - perfect

And: all the informations concentrated on just one display, just a fingertip away, no walking through the RV to get the desired informations.

@Wiki: you have done an unbelievable job, just have a beer now!

Spent money upto now:

Nextion 4.3" display
: 44€
- 4x Wemos D1 (will be less at the end of project): 10€
- 2xMPU6050 breakout board 2€
- 2XBME280 5€
- 1xBMP280 3€
- 1xNeo 6M GPS Sensor 8€
- 3D printer filament <1€
- 4-wire cables 5€
- 2x 3-port 12V/5V USB converter 6€
- 1x mini 12V/5V coverter 1€
Sum.: 85€

Free on market available device with similar functionality: None

Time invested on hardware production:
2 days for the floater, could have been less using more suitable devices
1h for magnetic fixing plate of levelling sensor

Time invested on typing rules and testing/calibrating 2h

Comfortable zone using this tiny little project in praxis: Unpayable

Influence of firmware ESPEasy: unpayable, without I personally wouldn't have been able to bring a project at this speed at this point.

Remember: In the past, 16 years ago, I designed and put into praxis an almost similar project in a timeline of 1 1/2 years!

.....to be continued, stay tuned...

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

User avatar
grovkillen
Core team member
Posts: 3612
Joined: 19 Jan 2017, 12:56
Location: Hudiksvall, Sweden
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#44 Post by grovkillen » 16 Jun 2020, 21:55

Thanks for the feedback, much appreciated!
ESP Easy Flasher [flash tool and wifi setup at flash time]
ESP Easy Webdumper [easy screendumping of your units]
ESP Easy Netscan [find units]
Official shop: https://firstbyte.shop/
Sponsor ESP Easy, we need you :idea: :idea: :idea:

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#45 Post by TD-er » 16 Jun 2020, 22:19

I was thinking about the kind of documentation we are missing for new users.
Most of our documentation does require some basic knowledge of what ESPEasy can do and how to do it.
It is more like a reference.

So what we do need is to describe a use case to which people can relate and is not too far fetched or artificial just made up to describe some feature.

I think this project could serve as a good use case to describe step-by-step a problem and how it can be solved using ESPEasy.
And the nice thing is, you can extend the problem set with new things to solve and still maintain a story line throughout the introduction chapters.

So keep us posted with your project :)

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#46 Post by Wiki » 16 Jun 2020, 22:31

Exactly this was my intention to document a project inside this forum in this manner. Most projects posted here are one picture of a mini OLED with some temperatures on it and some cable stuck into a breadboard or soldered. Its a pity - ESPEasy is such a mighty tool. I am used to present other documentations, like the one I am doing here. Just to present step-by-step what you can do with this outstanding firmware and how - and how easy. And to give ab idea, what could be done with these tiny small pcbs and the firmware.

In other places I asked the admins to close the thread for answering for others than me and open a parallel thread where things could be discussed. I missed it this time, because in the beginning there were no comments. Probably we could heal this?

I could have opened an own blog, a thread in a rv forum or whatever. The key component of this tiny small project is ESPEasy and so I felt it belongs to here.

Thank you for the flowers....

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#47 Post by TD-er » 16 Jun 2020, 22:40

Wiki wrote:
16 Jun 2020, 22:31
[...]
In other places I asked the admins to close the thread for answering for others than me and open a parallel thread where things could be discussed. I missed it this time, because in the beginning there were no comments. Probably we could heal this?
[...]
You mean a topic closed for replies, just for documenting it?

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#48 Post by Wiki » 16 Jun 2020, 22:48

And here a result of putting the recorded data into the GPX-Viewer I've linked above to:

GPS11.JPG
GPS11.JPG (126.9 KiB) Viewed 2756 times
nice, isn't it?

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

Wiki
Normal user
Posts: 275
Joined: 23 Apr 2018, 17:55

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#49 Post by Wiki » 17 Jun 2020, 00:35

TD-er wrote:
16 Jun 2020, 22:40
Wiki wrote:
16 Jun 2020, 22:31
[...]
In other places I asked the admins to close the thread for answering for others than me and open a parallel thread where things could be discussed. I missed it this time, because in the beginning there were no comments. Probably we could heal this?
[...]
You mean a topic closed for replies, just for documenting it?
Yep, if seen as helpful

Code: Select all

pi@raspberrypi:~ $ man woman
Kein Handbucheintrag für woman vorhanden
pi@raspberrypi:~ $

TD-er
Core team member
Posts: 2881
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: ESPEasyRV Electronical Upgrade of a Motorhome

#50 Post by TD-er » 17 Jun 2020, 09:00

Well I think since the project is now in development it may be of added value to have the option to discuss it along the way.
Afterwards we/you can summarize it on the wiki and/or we format it into the ReadTheDocs.

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests