[moved from detailed topic]
Update: see my second post from today; the issue seems to be the pimatic-dewpoint plugin!!

Gents,
I’m trying since once week to migrate my production from 8.107 to 9.x - and I have a strange and serious issue here: After a deep and intensive root cause analysis I must state that the MQTT- plugin prevents me from a successfully migration (and this is really a critical core component within my complete setup - as the MQTT broker connects my different architecture layers and components).

The behaviour is as follows:
as soon as MQQT plugin loads more than 2 (or 3) devices after rendering is finished, one of the CPU goes to 100% and memory usage raises slowly but continues to max if i don’t kill the pimatic-node process. Also in this stage no connection from web-frontend possible anymore (gets time-out).
Then after around 1-2 minutes, the debug messages says that mqtt-broker(s) got disconnected.
I checked in parallel with netstat all protocols and pipes during pimatic load - the connections are establised).
Therefore I assume that this is a) a memory problem - b) a kind of ‘load’ problem when mqqt-plugin tries to get data from the devices or c) at least some major component of pimatic get’s in trouble.

Environment: 'Pre-Production new’
If I set the plugin to use the local mosquitto instance “localhost” on the pre-production raspi (who don’t get any data) it works.
But as soon as I put the IP-adress from the production-broker in here, it fails with above behavior
Same behavior if I switch test-wise the ‘pre-production new’ to production (change hostname/IP-address etc.)

I tried every possible combination and variant (one broker setup, two broker setup etc., changed ports). All versions checked: 0.9.0,0.9.2,0.9.3,0.9.5.
This problem is re-produce able: as soon as I delete the mqtt-devices the startup finished normal (or in multi-broker environment reference as default to ‘localhost’; as soon as I add more than 3-4 devices to the ‘production-broker’ it got the crash
In my production environment (Raspi B+/Wheezy, pimatic 0.8.107, mqtt-plugin 0.9.0, node 0.10.24) the same pimatic config-configuration works flawless since years.
Also the parallel ‘pre-production old’ (0.8.107) where I also reference as above to the production-broker to test data

My conclusion is:
The setup on the new machine (‘pre-production new’) has two major differences:

Wheezy->Jessie
-Node V0.10.24.x -> V4.6.2
Therefore it must be one of this environment which causes this behavior.

Any hints???
I’m really at the end of my skills (and I can say that I’m a linux / pimatic pro)

My setup (target machine ‘pre-production new’):
-Raspi V2 (I tried this also with V3 - same behaviour)
-Jessie: Complete fresh setup from last jessie image and all updates/upgrades .
-Same issues/behavior with an previous update from the old working ‘pre-production old’ (wheezy) to jessie / older jessie image from August 2016
-Node: v4.6.2
-pimatic: 0.9.38
-mqtt broker: mosquitto (V1.4.10) on production and pre-production; tested also ‘old’ V1.3x -> same behavior

plugins loaded (all fresh installed within initial bootup):
pimatic-cron
pimatic-dewpoint
pimatic-dht-sensors
pimatic-echo (also disabled this testwise)
pimatic-gpio
pimatic-hap (also disabled this testwise)
pimatic-homeduino
pimatic-hue-zll (also disabled this testwise)
pimatic-mobile-frontend

pimatic-mqtt

pimatic-ping
pimatic-pushbullet
pimatic-shell-execute
pimatic-sunrise
pimatic-youless
sqlite3

ok guys: as nobody replies to this I mentioned that this must be a very ‘specific’ issue on my side. After spending additional nights analyzing the issue:

It seems that NOT the mqtt-plugin is the ‘issue’ but the pimatic-dewpoint plugin.

A specific problem in the sence that I’m using this plugin very excessive to calculate the dewpoints from different temp. sensors which are coming from the MQTT devices. Then I’ve defined some expression variables which calculates the differences of max/min temperatures In the background. I’m using these variables and logic for a ‘high sofisticated’ automated fan-control to handle humidity in my cellar); see appendix

After investigating the changes which has been made to this pimatic-dewpoint plugin: this has been changed in some parts (i used V 0.8 in the current pimatic 0.8.107 setup which works flawless): esp. the format (see device-config-schema.coffee ) has changed from “string” to “metric”:

units:

     description: "Units used for Temperature (metric/imperial/standard)"

deleted type: "string"
added enum: [“metric”, “imperial”, “standard”]
default: “metric”

An additional change is, that the plugin calculates the absolute humidity in g/m3 now.
I’m not sure which if this changes causes the issue, but i assume some changes how numeric data is handled.

I tried to revert this to string in the code but doesn’t work. Using the old version of the plugin nether as dependencies are not met.

Therefore the question is: has there been any pimatic internal changes in V0.9 how number-units are handled???
There seems to be a new choice between “metric”, “imperial”, “standard”.

My input data from mqtt-devices are normal 'number’s

BTW:
And now I understood: this is exactly the reason why my issue is so re-produceable:
If i reference to the mqtt-broker in the pre-production, he gets not data and the relevant pimatic-dewpoint devices are not triggered/calculated.
As soon is a reference to the production mqtt-broker, the above described behavior occurs as soon as the first temp. data arrives from an MQTT temp. sensor device. I can see in the frontend that the graph for the dewpoint device is building up and in the next second CPU goes to 100% and connection to frontend get lost / after a while also the mqtt-connection. Here I guess a problem with the sockets occurs in pimatic-memory.

Appendix:

1. MQTT sensor

{

  "name": "Sensor-IoT AZ",
  "id": "iot-client-6",
  "class": "MqttSensor",
  "attributes": [
    {
      "name": "IOT-temperature",
      "topic": "xxxxx/home/IoT/ESP_8B9066/temp",
      "type": "number",
      "unit": "°C",
      "acronym": "T1",
      "discrete": false
    },
    {
      "name": "IOT-humidity",
      "topic": "xxx/home/IoT/ESP_8B9066/humidity",
      "type": "number",
      "unit": "%",
      "acronym": "RH",
      "discrete": false
    },
    {
      "name": "IOT-temperature-2",
      "topic": "xxx/home/IoT/ESP_8B9066/temp_dallas",
      "type": "number",
      "unit": "°C",
      "acronym": "T2",
      "discrete": false
    }
  ]
},

2. Variable

{

  "name": "dewpoint-diff-AZ",
  "expression": "$dewpoint-iot-client-6-dallas.dewPoint - $dewpoint-iot-client-16.dewPoint"
},

3. Dewpoint device

{

  "id": "dewpoint-iot-client-6-dht",
  "class": "DewPointDevice",
  "name": "Taupunkt-IoT AZ-DHT",
  "temperatureRef": "$iot-client-6.IOT-temperature",
  "humidityRef": "$iot-client-6.IOT-humidity"
},

4. calculation variables (one for each max/min calculation for specific sensors which are validated against a reference point later)

{

  "name": "dewpoint-diff-AZ",
 "expression": "$dewpoint-iot-client-6-dallas.dewPoint - $dewpoint-iot-client-16.dewPoint"

},

5. Rule to trigger something

{

  "id": "dewpoint-check-az",
  "name": "dewpoint-check-AZ-max",
  "rule": "if $dewpoint-diff-AZ is greater or equal than $threshold-dewpoint-diff-uppertrigger and $dewpoint-diff-trigger-AZ is 0 and $dewpoint-iot-client-6-dallas.humidity is greater or equal than $threshold-humidity-lowerlimit-AZ then set $dewpoint-diff-trigger-AZ to 1 and push ..."
  "active": true,
  "logging": true
},

@fennsen some hours later the problem is solved:

indeed it was the combination of dewpoint devices and calculating expression variables;

The issue was caused by a combination of tricky circumstances:

1. The new dewpoint plugin seems to handle the non-discrete values in another way.
   My calculations variables referenced to the xxx.humidity and xxx.temperature values of the dewpoint device.

2. As the migration on existing DB failed, I let pimatic setup a new database on startup.
   As this are discrete values and in my setup only written every 5 minutes to DB, pimatic got confused during startup, because the values wasn’t some kind not right there at this time. So it seems that pimatic tries to calculate and waiting for the data (CPU raises to 100%… memory overflow). Depending on the sensors this needs some minutes to populate all the temp & humidity values; during this time the dewpoint values are not there and pimatic tried to calculate and wait in memory (endless loop i guess)

It took me days to get to this point where the real issue was.
I’ve had to fixed this by disabling all the relevant stuff upfront:

• Opening a htop window in parallel to see exactly the behaviour and the concrete point at which the memory and cpu get crazy;

1. deleting all relevant devices, variables, and rules

2. Step by step enabling again:
   2.1 add devices (->ok)
   2.2 add variables 1by1 (->here it crashed the first time->root cause analysis)
   2.3 add rules 1by1 (->here it crashed the second time->root cause analysis)

Long story short outcome - lessons learned:
Don’t expect a smooth migration to 0.9 if you have a very complex installation, a lot of rules and/or expression variables which might fail due to changed taxonomy and/or data types / other changes in the plugins.

2. disable IPV6 if possible (the listener sometimes switched the listening port to the ipv6 stack; client connected but fails to communicate)
3. If you use MQTT: don’t use ‘localhost’ as the default. Use “127.0.0.1” or the dedicated IP-adress of the broker machine. If you have ipv6 stack enabled it’s a questions of luck which path he takes for connections

Good luck and have fun!