you're telling me, even if they do reach out I doubt I can afford them.
@chuck.schwer: New product line: Sell the HE OS as a package to install on bigger hardware with a full dev kit. Problem solved. 
3 Likes
I believe Bruce when he says that they use the same tools.
What I say is that they can also say, as they built the java environment, what can trigger errors or not.
I believe what the developers here are asking is to have an understanding if there is a error in the code write up or if there is an exception with core structure that requires a specific format being parsed or if there is a memory leak error.
And give others the opportunity to build q better product?! Bad approach that only works with open source I dare to say....
Hi guys, topic started good and is going bad.
Do'nt accumulate hard words pushing the counterpart to a dead corner. The extreme situations will likely never happen.
Personally I like to be able to write an app, less to write a driver...
True. It was mostly a joke. Granted, I know I would pay to have the HE OS running on a 16 core/32GB RAM machine. 
2 Likes
No worries about that...
From my end I always take these vivid discussions with the relativity they require.
It's a learning experience as it allows a better understanding of what moves the HE core team.
Sometimes is not so much about what is being discussed but what is being said by unspoken words.
So is like in any situation in life when you interact with others and where you are trying to get an agreement about something. First there is a clash of arguments, than radical extrapolation of point of views, than a few eureka moments, than progress is made.
It does not matter so much which side is vitorious if in the end you end up with a better outcome.
If we all share the same point of view and opinions progress would not exist...
I think it's a bit difficult for those of us that make up the "innovators" or "early adopters" part of the product (or service) adoption curve to realize we are but a small minority of the audience market if and when the product (or service) makes it across the "chasm" where the bulk of the consumers (early majority and late majority) live. The key is that our enthusiasm and our shared experience with the product (or service) in the early stages may be a key to whether the product (or service) is able to make it to the next phase and succeed there.
To be honest, I'm not a fan of webCoRE on HE. I was happy with it on ST when it was cloud->cloud and there weren't any better rule engines available.
On HE though, I just don't see the point of it with Rule Manager, Maker API and web sockets being available.
1 Like
That's fair. I rely on the websocket api for this project as well. I was trying to write a test engine for webcore back during the daylight savings time issues and got a little carried away with it. It was very fast on an i3 with an ssd, but I'm running it on a raspberry pi as all that horsepower was a little overkill. My hub runs all the drivers, and it links up to this engine to run webcore and other custom apps.
This was mostly just a fun side project though. From what I've read the HE hub has a better CPU, so it should be enough to handle most any apps if they are well coded.
1 Like
Errors are reported to the Logs, and typically identify the source code line number that caused it. This is a primary means of debugging code. Another primary means is to instrument the code with log.debug statements, revealing the inner workings of the code. These are removed once whatever issue being chased is resolved. A third primary means is the application status page, where all settings and state are displayed. Anyone who writes code for this platform presumably knows enough to already be aware of these things. There is no magic to it, just straight forward software development effort. For something like an infinite loop (and by inference, memory leak), any coder is pretty much on their own to figure that out, as it will have devastating consequences. I've certainly done this to myself more than once, but I'm usually pretty aware of the risk.
2 Likes
This exactly. There are a number of apps out there where users add all their devices just so it's available the app even if they don't use it. The app then subscribes to every event of every device. That can bog the system down. Then if the app does a http call for every event it just gets worse. I've seen this on a number of apps and end up modifying the app to strip out everything I don't need and reducing the over head.
The good old days. I remember writing assembly code on my PC AT and using debug to step through machine code.
You are not alone. Luckily I was able to get to the reboot url still.
1 Like
Probably going to show my age here, but I remember writing code in Fortran and COBOL using punch cards in college. I also remember when there was a time I thought that we didn't need anything faster than a Pentium processor. Those were the days.....
3 Likes
Assembler on the DEC PDP8. I am OLD!
2 Likes
Yep- showing that you're right about my age.
1 Like
You mean there are people here who DIDN'T write Fortran on punch cards?
1 Like
I used to be able to read 8 level paper tape like reading a book. You know, the punched paper tape from an ASR-33 Teletype? I am a relic.
Thank you all for making me feel young again.
1 Like
If the problem was just a ton of subscriptions and HTTP(S) requests, I'd expect to see sluggishness all the time. Let's use InfluxDB as an example. Once it's created all of its subscriptions and made its first batch of HTTP calls, it's got what should be its basic resource footprint. Assuming no subscription changes are made, its demands on the system shouldn't really increase or decrease.
Since the hub runs for weeks at a time before grinding to a halt, that suggests that there's some sort of slow resource leak that doesn't really have any effect until it hits the point of exhaustion and the whole thing goes belly up.
