you can use receive_data...

thats tcp/ip, a message came within one, two or more packets. you have to sum the messages up in a string-variable in the EVENT_RECEIVE_TEXT function. than you have to look at a EOM (end of message) byte or text.

than you have to strip the part of the string-variable that you decoded, because maybe you have also another messages appended to the first one, etc...

iridium doesn't know when the message from a tcp/ip device is "done", so most of the times it works with one packet and one message, but i have for example a heating control here that sends out a xml-message that comes within 10 packets.

ok

Maybe a "auto-reset-scale" solution and/or a javascript command that could be triggered when pressing on the trendchart to do a new auto-scale when the user wants it.

The "upscaling" works fine, if a value higher the current view-range came up or below the current view-range of the y-axis, the graphic scales right. But then this scaling stays up forever. For example, we have a temperature sensor of a solar panel here. Winterdays, cloudy. The temperature stays at around zero degrees, little up little down, maybe 10 degrees up/down. When you start the iRidium panel in this situation, all is good you have a good resolution on the y-axis from lets say -2°C up to +10°C. So now the sun comes out and the temperature goes up to +90°C. All is working fine, y-axis scales so the max. value of +90°C is displayed correctly. Now the sun is gone and there are again a few cloudy days, temperature sinks down to around 0°C little up little down. But the y-axis max. value stays at +90°C and doesn't "fall" down to for example +10°C. even if the displayed timewindow is 1day, and the temperature is down below for 3 or 4 days. So you just see a line of the temperature at the bottom of the trendchart, but with a bad resolution. I think it would be the best when the values doesn't reach the limits of the y-axis scaling for around double or tripple the time of the x-axis time window, the y-axis should autoscale again to show the values in better resolution.

Another example is to use the trendchart as a power consumption chart in a house. Normally the value is for example around a few hundred watts, but can peak up to a few thousend watts. In this case, also the scaling would never reset back to a good viewing resolution when the power consumption stays at low levels for a longer time period.

Best regards,

Martin

hi, its a "standard" project with a few Custom TCP/UDP drivers with feedbacks.

the drivers receive infos from devices, parse them, and store them in the feedbacks.

but when uploading a new server project, even in development via transfer, the server

receives the new project and restarts. automatically null/zero values are stored in the database

right at the beginning, first data from devices came in a few seconds later after start.

it depends on feedbacks, not on command channels.

ok thx. this doesn't work with tcp server drivers on the server, but ok, its a solution. otherwise i think there are

solutions out for linux/raspian/etc so that a system is on standby and jumps in with the same mac/ip when the master system goes down, but thats a complete solution outside iridium server. best regards.

but the "online" check script on the panel is not a bad idea, could be also used to automatically switches between "home" and "outside" mode. check is the iridiumserver is online on the internal ip, if not, switch over to the public ddns adress... :-)

just make a button like for one channel, then drag'n'drop other channels as action too sending them the same value. but make a short delay between each channel with 20-50ms.

will this be a solution using the ha-bridge? or do you have something own in mind?

cool