In Comparison to highbyte Intelligence Hub(HIH) UM...
# umh-support
r
In Comparison to highbyte Intelligence Hub(HIH) UMH uses TimescaleDB while Highbyte uses InfluxDB. Further UMH uses Node Red and Highbyte Kepware. Further UMH hast hivemq included to build a unified namespace and hih has to be combined with hivemq. What are the Major differences between these two solutions besides from your Perspektive?
j
good question! we thought there is a lot of overlap to at the beginning, but then realized that it can be complementary. HighBytes strength is the data contexualization aka "Node-RED replacement" and if you use it like this, it is complementary to the UMH. Also HighByte does not use InfluxDB or HiveMQ by default, it is just a recommendation from their side. HoghByte is quite vendor agnostic when it comes to that and you can easily switch out e.g. HiveMQ with something else. btw: they have their own MQTT broker now We are even currently testing the combination of HighByte and UMH at one of our customers. There are some scalability and availability problems with HighByte in our opinion, but tools like Node-RED and Kepware suffer from the same problems (and are even worse in some regards). therefore, it could be a good node-red replacement.
also regarding Kepware: we are just amidst writing a tutorial on how to connect Kepware with UMH.
r
When you say there are scalability issues with Highbyte, do you mean architectural or UX? They've made some major usability improvements with 3.0 but I do have the same concern.
d
Highbyte runs exclusively on windows right? i see a lot of nice features in highbyte but also limitations and from my point of view(i have not tested it my self, only looked at videos) it feel like it is a little to simplified which for me is not good.
b
It can run on windows, Mac, and Linux. Also Docker.
r
Yup, it's Java based, same as Ignition.
j
As @Brian Pribe and @Richard Shaw already said, HighByte runs on Linux as well. We will test it in the next couple of days and try to deploy its Docker container in a Kubernetes cluster
With Scalalability and Availability I mean the capability to continue working even though software, hardware or human faults occur even though the load is suddenly increasing. Coming from a pure IT / Kubernetes / Netflix perspective, one would require clustering, load balancing, etc., so that if one instance fails, gets updated, etc., immediately another takes over. HighByte has that to some degree "primary/secondary failover" or "manual clustering requiring multiple installation". However, this will result in downtime and effort when trying to scale it up. You could now ask whether you actually need these requirements and this is something that we cannot decide for companies 🙂
we will also do some benchmarks and try to measure the behaviour when sending more messages and sending malformed messages. we've spend literally months to get this stuff for some of our microservices right, and there are still occasional hickups, like sending 2000 malformed msg / sec will start to block the system.
r
I see what you mean. I think that's also why part of their licensing strategy is per site so you can have unlimited instances instead of one huge instance that does everything.
3 Views