Rejoining a publisher's data stream
-
Guys one of our ES systems crashed and I rebuilt the new ES from a backup however there were a group of points recently added to the ES definition and publishing to destination that were not in the backup and so exist on the destination server but not in the new ES definition, Since I am unable to recreate these points, I seem to have trouble getting the new publisher to connect to the existing stream on the destination. I wonder if that is because the number of points are now different from what was last being transmitted.
If I prefix the XID's the Publisher's data it does create all the points new on the destination however I really want to reconnect to the existing DS on the destination. -
Hi Phillip,
Since I am unable to recreate these points, I seem to have trouble getting the new publisher to connect to the existing stream on the destination. I wonder if that is because the number of points are now different from what was last being transmitted.
Points not being present on the publisher will not affect the connection. Otherwise simply removing a point in the publisher's configuration would cause issues.
there were a group of points recently added to the ES definition and publishing to destination that were not in the backup and so exist on the destination server but not in the new ES definition
These are not the same points. The source points may have been something like Modbus points, which have information about acquiring their data over the Modbus protocol. New points, Persistent Receiver points, are created on the receiver, and then data is transmitted and synchronized. The information about the Modbus protocol in this example is not present on the received points to create again on the publishing points. Some data point properties, like logging type, are also not transmitted and therefore cannot be used to restore the previous configuration.
You could certainly use exports of the points on the receiver to assist in recreating the points you do not have a backup of, but it would still be a manual process.
If I prefix the XID's the Publisher's data it does create all the points new on the destination however I really want to reconnect to the existing DS on the destination.
You can simply use the prefix that you had been using, then. I would have expected that at least to be in the backup. If the publisher is not connecting for some other reason you could try enabling logging on the receiver and seeing if it is reporting any errors or warnings when the connection is being negotiated.
-
So I recreated the data sources using the same XID's of the previous points so the ES database has the same XID's and the same modbus offsets and slave id's, everything as the original ES. I compared the clouds points to the ES points and all are either numeric or binary and have same xid's. Still the publisher is not connecting. This is what the connection status is looks like :
/xxx.117.204.151:37986: 0 points, connected for 44ms, 1 packets received, 0 timeoutsConnection resets continually.
How do I enable the logging for the connection negotiation?
I was not using any prefix before.
I might add that the original ES was 288 and this replacement ES is 3.6.3 cloud is 3.5.6. -
The connection status on the publisher is more informative. But the logs on the receiver may be more useful.
This will produce a new log file in your Mango/logs/ directory that should identify itself as from the persistent module and have the ID of the data source in the log. In the old UI the path to the file is displayed.
-
Phil the log shows a java.lang.ClassCastException... ??
332 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT.initialize:250) - Initializing
INFO 2019-07-26 20:02:06,333 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT.initialize:281) - Initialized
INFO 2019-07-26 20:02:44,959 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT.run:417) - Received socket from /174.117.204.151:45714
DEBUG 2019-07-26 20:02:44,973 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:684) - /174.117.204.151:45714: client requested version 11
DEBUG 2019-07-26 20:02:44,974 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:692) - /174.117.204.151:45714: using version 10
DEBUG 2019-07-26 20:02:45,068 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:717) - /174.117.204.151:45714: authentication ok
DEBUG 2019-07-26 20:02:45,309 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:769) - /174.117.204.151:45714: ensuring point DP_770839, index: 1
DEBUG 2019-07-26 20:02:45,309 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.ensurePointV5:1079) - /174.117.204.151:45714: ensuring point DP_770839
DEBUG 2019-07-26 20:02:45,309 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.ensurePointV5:1089) - /174.117.204.151:45714: point DP_770839 already exists in RT list
DEBUG 2019-07-26 20:02:45,309 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.updatePointV5:1183) - /174.117.204.151:45714: saving point DP_770839 updates
DEBUG 2019-07-26 20:02:45,324 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:779) - /174.117.204.151:45714: confirmed DP_770839 with client
DEBUG 2019-07-26 20:02:45,325 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:769) - /174.117.204.151:45714: ensuring point DP_355921, index: 2
DEBUG 2019-07-26 20:02:45,325 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.ensurePointV5:1079) - /174.117.204.151:45714: ensuring point DP_355921
DEBUG 2019-07-26 20:02:45,325 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.ensurePointV5:1089) - /174.117.204.151:45714: point DP_355921 already exists in RT list
DEBUG 2019-07-26 20:02:45,325 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.updatePointV5:1183) - /174.117.204.151:45714: saving point DP_355921 updates
DEBUG 2019-07-26 20:02:45,326 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:779) - /174.117.204.151:45714: confirmed DP_355921 with client
DEBUG 2019-07-26 20:02:45,326 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:769) - /174.117.204.151:45714: ensuring point DP_707338, index: 3
DEBUG 2019-07-26 20:02:45,326 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.ensurePointV5:1079) - /174.117.204.151:45714: ensuring point DP_707338
DEBUG 2019-07-26 20:02:45,326 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.ensurePointV5:1089) - /174.117.204.151:45714: point DP_707338 already exists in RT list
DEBUG 2019-07-26 20:02:45,326 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.updatePointV5:1183) - /174.117.204.151:45714: saving point DP_707338 updates
WARN 2019-07-26 20:02:45,326 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.run:602) - /174.117.204.151:45714: Connection handler exception
java.lang.ClassCastException
INFO 2019-07-26 20:02:47,393 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT.run:417) - Received socket from /174.117.204.151:45716
DEBUG 2019-07-26 20:02:47,417 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:684) - /174.117.204.151:45716: client requested version 10
DEBUG 2019-07-26 20:02:47,417Data point Definitions on Cloud and ES:
Cloud Definition
{
"dataPoints":[
{
"xid":"DP_770839",
"name":"BOILER LOOP TEMP",
"enabled":true,
"loggingType":"ALL",
"intervalLoggingPeriodType":"MINUTES",
"intervalLoggingType":"INSTANT",
"purgeType":"YEARS",
"pointLocator":{
"dataTypeId":3,
"settable":false
},
"eventDetectors":[
],
"plotType":"SPLINE",
"rollup":"NONE",
"unit":"°F",
"simplifyType":"NONE",
"chartColour":"red",
"chartRenderer":{
"type":"IMAGE",
"timePeriodType":"DAYS",
"numberOfPeriods":1
},
"dataSourceXid":"DS_060715",
"defaultCacheSize":1,
"deviceName":"QLOFTS-SYSTEM",
"discardExtremeValues":false,
"discardHighLimit":1.7976931348623157E308,
"discardLowLimit":-1.7976931348623157E308,
"intervalLoggingPeriod":15,
"intervalLoggingSampleWindowSize":0,
"overrideIntervalLoggingSamples":false,
"preventSetExtremeValues":false,
"purgeOverride":false,
"purgePeriod":1,
"readPermission":"User,PPolley,superadmin,user",
"setExtremeHighLimit":1.7976931348623157E308,
"setExtremeLowLimit":-1.7976931348623157E308,
"setPermission":"superadmin",
"tags":{
},
"textRenderer":{
"type":"ANALOG",
"useUnitAsSuffix":true,
"unit":"°F",
"renderedUnit":"°F",
"format":"0"
},
"tolerance":0.0
}
]
}ES Definition:
{
"dataPoints":[
{
"xid":"DP_707338",
"name":"BOILERS KWH",
"enabled":true,
"loggingType":"ON_TS_CHANGE",
"intervalLoggingPeriodType":"DAYS",
"intervalLoggingType":"INSTANT",
"purgeType":"YEARS",
"pointLocator":{
"range":"HOLDING_REGISTER",
"modbusDataType":"TWO_BYTE_INT_SIGNED",
"writeType":"SETTABLE",
"additive":0.0,
"bit":0,
"charset":"ASCII",
"multiplier":1.0,
"multistateNumeric":false,
"offset":576,
"registerCount":0,
"slaveId":212,
"slaveMonitor":false
},
"eventDetectors":[
],
"plotType":"SPLINE",
"rollup":"NONE",
"unit":"",
"templateXid":"BoilerkWh",
"simplifyType":"NONE",
"chartColour":"yellow",
"chartRenderer":{
"type":"IMAGE",
"timePeriodType":"DAYS",
"numberOfPeriods":1
},
"dataSourceXid":"DS_QLOFTS_HVAC",
"defaultCacheSize":1,
"deviceName":"QLOFTS-SYSTEM",
"discardExtremeValues":false,
"discardHighLimit":1.7976931348623157E308,
"discardLowLimit":-1.7976931348623157E308,
"intervalLoggingPeriod":1,
"intervalLoggingSampleWindowSize":0,
"overrideIntervalLoggingSamples":false,
"preventSetExtremeValues":false,
"purgeOverride":false,
"purgePeriod":1,
"readPermission":"superadmin",
"setExtremeHighLimit":1.7976931348623157E308,
"setExtremeLowLimit":-1.7976931348623157E308,
"setPermission":"superadmin",
"tags":{
},
"textRenderer":{
"type":"ANALOG",
"useUnitAsSuffix":false,
"suffix":" kW·hrs",
"format":"0.0"
},
"tolerance":0.0
}
]
} -
I noticed that the original Persistent data source has Point locator info for modbus in side its definition.
So I edited each one of these original Persistent TCP points that were offending and re-saved them and this removed that info and corrected the definitions inside the receiving points and the stream reconnected . Yahoo! Unknown how this modbus details got into the persistent DS to start with? -
Glad you got it figured out!
Unknown how this modbus details got into the persistent DS to start with?
These are the points that you emailed about wanting to recreate because they were missing from your backup, yes? If so, then surely you must have created them somehow. Offhand the only way I'm aware of to skirt type checking on points is to insert them via SQL. How did you create the points?