No, the timestamp would be when you receive the message. Of course there is a (small) difference to the time when the data was actually measured, but under normal operating conditions this should be very small.
This would allow you later to specify from which timeframe you want to retrieve data from the database.
I have not seen any devices that put a timestamp in the payload of the MQTT message.
It does not really affect me 
My network is similar to yours, only mosquitto is running on a Raspberry PI 4 (but it does only that so it is very fast as well).
mqttfx shows the subscribed messages as they come in, which makes it easy to look for what you mentioned.
MQTT Explorer allows to look a the history of each mqtt topic and shows the difference in timestamps. There i did see 60 seconds for some topics that did not change and varying intervals for the ones that change more often...
So I see "returned_energy" which is always 0 here, every 60 seconds there... I am not sure why it does that... 
Since we both seem to be getting all 18, would you also like to get them reported together in one json payload? It might make templating more difficult in HA, but the values at one point in time would be reported together. Perhaps the developer can make this an mqtt option.
Well, both ways (single messages, one jason payload) have their advantages and disadvantages.
But there is a much bigger problem. Allterco is working on the memory limit of the devices. Particulary in the 3EM this is an issues, so it may be very difficult to get them to implement anything else.
There are current bugs/limitations they try to get fixed in the 3EM and it already is a problem, so I doubt that something like this is likely to be considdered to be implemented soon...
But other than that I agree it would be great to have a choice on the data delivery (one jason, all messages together, only changes, selecting which values would be transferred by MQTT etc).
Also an option for a timed delivery even if nothing has changed would be nice (like tasmotas teleperiod).
Realizing the box may have set on the shelf for a while, the first thing I did from the dashboard was a firmware update.
Current version: 20210720-190729/v1.11.0-g6abd92e
You have latest version on your device!
Is this similar to yours?
Yes I have the same.
I get different results with different clients
iobroker and MQTT Explorer do not show me all 18 togehter, but MQTTfx does... Very strage.
But I would not bet on this to be guaranteed. Many MQTT devices have a (configurable) inverval at which to send all data and if a value changes in between it is send right away (and typically then just that value).
Hmmm this is interesting. I checked my 3EM (with MQTT Explorer and within iobroker) and I do not get all updated together... Which firmware do you have in the 3EM?
Das erste Shelly kann doch den zweiten Shelly fernsteuern. Auch wenn das erste Shelly nur den Taster hat. Short Press gleich erstes Shelly, Long Press gleich zweites Shelly.
Das wäre natürlich auch denkbar. Aber wenn man 2 Taster hat (und auch noch ein Shelly 2.5 rumliegen hat), dann ist es sicherlich komfortabler wenn jeweils ein Taster eine Sorte Lampen schaltet...
Wenn dem so wäre, Dann kann Woll-E den 2,5 an die Seite legen, und alles beim Shelly1 eingeben, wo die Taster angeschlossen sind...
Der 2. Shelly 1 ist ja NICHT bei den Tastern verbaut. Insofern braucht er da entweder ein Teil was ihm noch einen weiteren Schalteingang gibt (z.B. ein i3) oder er ersetzt den Shelly 1 im Schalter mit einem Shelly 2.5
Hab ich auch so verstanden...
Und der Shelly 1 (erstes Shelly 1) wird nun durch ein Shelly 2.5 ersetzt...
(damit zu einen die Funktionalität des alten Shelly 1 bleibt, aber ein 2. Eingang benutzt werden kann um den zweiten Shelly 1 remote zu schalten.
Nochmal zur Lösung:
Als erstes würde ich versuchen von einem Computer oder Handy das URL Kommando zum schalten des Shelly für die Wandlampen abzusetzen. Wenn das funktioniert, dann die Kommandos in den Shelly 2.5 "eintragen".
Ich hab so so verstanden, dass er einen Shelly 1 hat, der die Wandlampen steuert und dieser NICHT in dem Schalter verbaut ist. Er hat ja geschrieben, dass er den 2.5 nimmt weil er den schon hat...
Deswegen mein Kommentar, das für einen Schalter wo nur eine reine Schaltfunktion ist der i3 die bessere Lösung ist...
Einen weiteren Shelly 1 hat er wohl jetzt schon hinter dem Taster für die Deckenbeleuchtung.
Wenn ich das jetzt richtig verstanden habe wird der Shelly 1 hinter den Tastern durch einen Shelly 2.5 getauscht, wobei da nur ein Relais in Betrieb ist (für die Decke) und der 2. Eingang dann den woanders verbauten Shelly 1 für die Wandlampen schalten soll... (Korrekt?).
In der Tat wäre ein Shelly i3 die bessere Lösung als ein 2.5. Nicht nur dass er Dir mehr Möglichkeiten für die Actions eröffnet er ist auch kleiner und hat 3 Eingänge...
Ansonsten geht es natürlich auch mit einem 2.5 wie oben beschrieben.
There is no fixed MQTT send interval. You get new MQTT messages only if there hase been a change.
And you only get messages for the values that have changed.
So you can not expect 18 messages to come every time, since you only get changes...
So you will need a different approach. Depending on what you are trying to achive there are many options. You could store each incoming message with a timestamp in the database, or you could define a short timeframe where you accumulate data and store that.
Typically several messages will come togehter because a change in the measured voltage or ampere will result in a change for power or energy...
I have also noticed that it seems to be helpful to delete all data (through the 3em web interface) once after installation is complete. I did have some strage data in the beginning, but after deleting the data once, the CSV data came in with correct invervals.
DC current is fairly easy to meaure with the use of a Shunt resistor. I believe the accuracy of the ADC in the UNI should be good enough for that. However you will need a small circuit to amplify the voltage from the shunt to the range that the UNI can measure. Most shunts have about 50 or 60mV / A, so depending on what range you want to measure you may have to amplyfi this a little bit.
...und da die Software ja denkt, dass 120A Meßadapter angeschlossen sind, werden die Werte zusätzlich auch noch um den Faktor 120/50 falsch sein.
Also wenn der PF auf 0,4 oder so sinkt, dann ist sicherlich was nicht in Ordnung.
Unabhängig davon gibt es Zuhause auf Verbraucher, die "plötzlich" angehen auch wenn niemand zuhause ist (z.B. Kühlschrank, Heizungspumpen etc..). Das kann also schon sein.
Allerdings ist noch etwas anderes an Deiner Beschreibung merkwürdig. Du schreibst 150W Grundverbrauch und 300W wenn die Solaranlage läuft. Wo misst Du denn??? Wieviel W hat die Solaranlage?
Ja, folgende info habe ich vom Support dazu bekommen:
Try to use the units with their current FW version until we find the issue and resolve it.
Ich hab auch über 50 Shellies (und insgesamt über 100 Teilnehmer) an einem WiFi AP (UniFi). Das geht also. Auch die Belastung des WiFi ist eher gering.
Wie schon geschrieben ist es dabei wichtig einen Leistungsfähigen AP zu haben. Die meisten Billigrouter dürften bei so vielen Teilnehmern schon eher Probleme machen.
Wie lange dauert die "Fahrzeit" jedes mal? Kann es sein, dass die "Open/Close working time" Einstellung greift?
Wenn Du sowieso nur die Endpunkte anfahren willst, dann ist die Kalibrierung auch nicht wirklich nötig.
If there is a phase shift between the phases (which the shelly 3EM does not meaure) the results will be off.
