## 6 Discussion  
The typical smart microgrid, consisting of consumers, a power generator, power storage, and a control unit, can already be delivered, but in most cases, all from a single source. Without appropriate standards, however, this CPES will remain an island in a multi-stakeholder smart grid. The example of energy management shows that more complex CPES will only be possible using a mix of several standards for different tasks. For the time-critical communication processes in CPES, such as switching operations in power grids, other advanced technologies are needed. The standards presented here are not--or are only partially--suitable for this purpose. Comparing our two presented use cases, we can state that the non-standardized solution in the first case was easily installed because the product and IoT cloud came from the same manufacturer and worked well together. The usability of this solution was subjectively perceived as being good. For simple monitoring, one can stop at this point, leave the meter data in the manufacturer's IoT \begin{table}
\begin{tabular}{l r r} \hline \hline  & **Case 1 (without Standards)** & **Case 2 (with Standards)** \\ \hline Sensor configuration (per sensor) & 1.5 h & \(<\) 0.25 h \\ Sensor configuration (once per setup) & 0 h & 3 h \\ Energy Management System (EMS) & 128 h & 720 h \\ implementation (once) & 0.5 h & 0.5 h \\ EMS configuration (once per setup) & \(<\)0.25 h & \(<\)0.25 h \\ EMS configuration (per sensor) & 0 \(\copyright\) & 900 \(\copyright\) (market price) \\ Hardware variable costs per sensor & 210 \(\copyright\) (market price) & 60 \(\copyright\) (estimated w/o cu. transform) \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Cost comparison (h = working hours). cloud, and be satisfied with the rudimentary visualization offered. For application in heterogeneous Smart Grids, this solution would be possible, in principle, through an API. However, for every other manufacturer, new API connectors would have to be programmed, which would mean disproportionately high development expenditure. Therefore, we do not consider this approach suitable for Smart Grids. In applying our EMS, the development of an API connector containing a user interface for configuration took 128 h of effort, which is only worthwhile if a larger number of sensors from the same manufacturer's IoT have to be connected. If, however, the data are to be processed in a heterogeneous CPES and combined with data from other sources, the need for standards becomes clear. Our second setup showed the use of open standards. LoRaWAN was applied for the radio connection. As this is the only LPWAN technology available on the market for self-operation, using NaaS was not considered in this application. The LoRa deployment showed it is particularly suitable for CPES. The radio coverage of a base station of several kilometers should be sufficient for most smart microgrids; the good building penetration offers reliability and the various device classes allow for battery-powered sensors with a service life of up to 10 years. The need for strong security mechanisms is also met by the LoRa architecture, as the data is transmitted with AES-128 encryption and operator and application data can be separated using a network key and an application key. In summary, LoRa can be certified as being highly suitable for use in smart grids, at least if the application does not require time-critical transmissions or large amounts of data. Regarding standardization, LoRa's Achilles' heel is the freely configurable user data package, so cross-manufacturer radio components, in particular, cannot be combined or can only be combined with a certain amount of effort. In the example shown, vendor-independent standardization has only become possible by exposing a non-standardized LoRa data frame in the standard notation. This step meant great impairment of usability. A transfer of this JSON description into the configuration of the base station provides the semantics of the sensor data.